CAO architecture

As shown in the diagram above, an ORiN2 program on PC consists of three layers.
The first layer is the CAO application part. By using a standard program interface provided by the CAO engine, client applications can be developed with no need to consider differences between devices (*1). In addition, more than one of the client applications can be activated concurrently.
The second layer is the CAO engine part, which has the same functions as a standard program interface. It also offers a standard program interface for client applications and provides common functions including provider management and asynchronous processing.
The third layer is the CAO provider part, which is a module with device interfaces to absorb differences between manufacturers. In addition to the implementation of device interfaces, the providers allow CAO to flexibly expand to add new functions.
CAP and CRD, which are mentioned later, use the providers to perform their functions.
*1) While there is no need to consider access with communication devices or access in the protocol (algorithm), it is necessary to consider the information in the devices.

■CAO engine

■CAO provider

CAO providers are called dynamically by the CAO engine according to the request from client applications. They are designed to function as add-ins of the CAO engine and implemented as DLL-type COM components.
CAO providers are not directly accessed by client applications but called by the CAO engine and other CAO providers only. Accordingly, users do not have to consider the interface specifications of CAO providers.
They can be created with the provider creation wizard included in ORiN2 SDK and always have the same interface ID for the CAO engine. (The class IDs are unique to respective providers.) As a result, even if different CAO providers are linked to the CAO engine, they can be called exactly in the same way. This mechanism allows CAO providers to function as add-ins for the CAO engine.
There are many types of CAO providers including device, data sharing, utility and gateway types. The device type is implemented in a way which absorbs the differences between communications specifications of the actual devices to which they are connected for the CAO engine. Standard CAO providers fall into this type. The data-sharing type shares data between different applications, including shared memory providers and CRD providers with access to XML. The gateway type connects with standards other than ORiN to serve as a bridge for data and commands, including providers to connect with OPC established by the OPC Foundation as well as providers to connect with RAO, specifications of ORiN version 1.
Other types of providers can also be created flexibly depending on the implementation. For example, virtual-equipment providers can be used for preliminary verification before the introduction of a system because the operation of the target equipment can be emulated only with software without connection to the actual equipment.

■CAO object model

The CAO object model is the abstraction of volatile and nonvolatile resources in the devices covered by ORiN2. Volatile resources include messages and commands, which are handled by the CaoMessage object and CaoCommand object. Nonvolatile resources include controllers, variables, files, tasks, robots and expansion cards, which are handled by the CaoController object, CaoVariable object, CaoFile object, CaoTask object, CaoRobot object and CaoExtension object, respectively.
In the meantime, the CAO engine is handled by CaoEngine object while information on the status of the CAO engine and also workspace to place controllers are handled by CaoEngineStatus object and CaoWorkSpace object, respectively. Other objects include collection object, which collectively manages multiple CAO objects.

The target devices for ORiN2 are classified into the pull type (store type) and the push type (event type). Pull-type devices have an internal area to store values, and return values according to external requests. Push-type devices transmit externally the values they contain, with arbitrary timing.
In ORiN2, the information on the handling of push-type devices sent from devices by transmitting the CaoMessage object to OnMessage events of the CaoController object can be collected by client programs. It is also possible, with specification of the operation mode, for the CAO engine to store the information sent from devices in the CaoMessage object, accumulate the object in the pool and send the information to client programs, with arbitrary timing.