For system integrators Outline of CAO

Outline of CAO


CAO, which stands for Controller Access Object, is a standard program interface that provides client applications with interfaces for access to devices. In general, CAO refers to the CAO engine and CAO providers.

CAO architecture
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

The CAO engine is an EXE-type COM component that plays the core role in ORiN. It intermediates between client applications and CAO providers to exchange data and commands between them. Client applications are always linked with the CAO engine, which is linked to the necessary CAO providers according to the client request. The links between client applications and the CAO engine, as well as the links between the CAO engine and CAO providers, can go beyond processes, PCs and the Internet, because they are based on the specifications of DCOM or CORBA, a distributed object technology.
This function also enables client applications to perform remote access and load distribution easily.

  • CAO provider management
  • Object collection management
  • Asynchronous processing with a message pool (event processing)
  • Context management by converting messages into objects
  • Advance registration of objects (CAO model)
  • Dynamic API change by dynamic binding
  • Static information merge processing with CRD files
  • Connection to remote engines

While the CAO engine and CAO providers included in ORiN2 SDK are “implemented” with DCOM, CORBA is also compatible with the specifications of ORiN2. ORiN2 SDK also includes CORBA IDL files.

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

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.

CAO object model

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.

In this website, CAO application, CAO engine and CAO provider are also referred to as ORiN application, ORiN engine and ORiN provider, respectively.