【
】
ORiN2.1 Specifications
Part 1: Outline
Version 2.1.0
November 18, 2008
1

【 Revision history 】
Date Rev.
2005-08-25 1.0.0
2008-11-18 2.1.0
Content
2

3
1. Background..................................................................................................... 4
2. Technology outline .......................................................................................... 5
3. Range of modeling.......................................................................................... 6
3.1. Nonvolatile resource and volatile resource ........................................................................................ 7
3.2. Pull type device and push type device ............................................................................................... 7
4. Outline of CAO ................................................................................................ 8
4.1. Object model of CAO ......................................................................................................................... 9
4.2. Function of CAO .............................................................................................................................. 10
5. Outline of CRD .............................................................................................. 12
6. Outline of CAP .............................................................................................. 14
Appendix A. Glossary........................................................................................ 15

4
Recently, the number PC application programs in the factory is increasing. Various application programs like production management system, process control system, operation monitoring system, and trouble analysis system, etc. operate at the factory, and they are becoming keys of the manufacturing system.
However, most of these PC applications are developed only for a specific manufacturer and a specific model. This is because they are "a la carte" application that depends on specific proprietary networks and proprietary protocols.
Once such a system is introduced in a factory, a full-time working software developer is required to reside in the factory to continue the improvement of the system. Otherwise, the system will be far from really usable one, and will be left in the factory without any improvement. Such a state decreases the cost effectiveness of the system, and decreases the value of the system itself.
In addition, because the product demand increase is very steep recently, failure to catch up the demand will mean the opportunity loss. Therefore, each manufacturing companies are trying achieving vertical start-up of equipment. To achieve this goal, high reusability of hardware and software throughout the equipment life cycle is very important.
The reusability of “a la carte” software becomes very low.
To cope with the situation, ORiN was developed to prepare standard PC application network. ORiN is an abbreviation of Open Robot/Resource Interface for the Network, and it is a framework to handle wide range of resources like robots and various FA equipments. By using ORiN, manufacturer and model independent applications can be developed, and the reusability of PC application program will be greatly improved.
The ORiN project started in 1999, and ORiN Version 1 was released in 2002 as a result of the project. ORiN version 1 was applied on various FA applications, and based on the technologies developed through the applications, new standard of ORiN version 2 (ORiN2) was released. This document is specifications of ORiN2.

5
ORiN2 is middleware that provides a standard program interface for FA devices (equipments) such as industrial robot, PLC or NC, and has the following features.
•
Independence from programming language
•
Independence from communication protocol
•
Network transparency
Independence from the programming language means that various programming languages can be used
Independence from communication protocol means that the middleware does not rely on manufacturer proprietary protocol. Network transparency means that implemented module can be placed anywhere on the network and it can be accessed transparently from client applications.
ORiN2 is composed of the following three technologies.
1 CAO-standard program interface (Chapter 2)
2 CRD-standard data schema (Chapter 3)
3 CAP-communication protocol for Internet (Chapter 4)
CAO (Controller Access Object) is based on distributed object technology, CRD (Controller Resource Definition) is based on XML technology, and CAP (Controller Access Object) is based on SOAP technology, respectively. The
relationship between these technologies is shown in Figure2.
⇒
⇒
⇒

6
The specification of ORiN is defined in the viewpoint of "How are the resources in the device is opened to the public". ORiN defines a device model of abstracted FA device, and the modeled resources are shown in
File
Task （ job ）
Message
…
File management
Expansion card
Task
・ Language interpretation
PC
Controller （ main ） …
Command
Teach Box I/O Variabole
Robot management
Volatile resource
Non-volatile resource
Trajectory
Servo
FA device
Figure3.
To use ORiN, not all of these resources are required, but only at least one resource that matches ORiN model is required. This lax restriction enabled utilization of ORiN with various FA devices.
Message
…
File
Task （ job ）
File management
Expansion card
Controller （ main ）
Task
・ Language interpretation
Teach Box
Non-volatile resource
FA device
I/O Variabole
Robot management
Trajectory
Servo
…
Command
PC
Volatile resource

7
Resources managed by ORiN can be classified as nonvolatile and volatile. For instance, resources like I/O and register variable of PLC (Programmable Logic Controller) exists as long as the power is supplied to the device. These types of resources are called as nonvolatile resources. On the other hand, a message character string generated by a device or command character strings sent to a device are called as nonvolatile resource. Both types of resources are modeled in ORiN
ORiN can manage two types of devices, i.e., a pull type (store type) device and push type (event type) device. For instance, most of PLCs or robot controllers are pull type device, and their resource data is accessed from the outside.
A characteristic of a pull type device is that it has "present value". Oppositely, a push type is the kind of device that pushes out data from the device, like a bar code scanner.

8
CAO (Controller Access Object) is a specification that becomes the nucleus of ORiN and defines a standard program interface. CAO is based on the distributed object technology. CAO consists of two parts, the engine part and the provider part. The engine part defines the sole application program interface. The aim of the engine part is to offer a generalized function that does not depend on each FA device. Oppositely, the provider part is a module that absorbs the differences between the CAO abstraction device and the actual FA device. The provider part defines the sole
interface to the engine part. This is called as device interface. (Figure4)
A Co.
B Co.
C Co.
D Co.
Because of the structure of CAO, application program developers can develop applications that do not so much depend on the devices, and device manufactures can open device functions to the public without depending on the type of the applications using the devices. Moreover, by dividing the engine part and the provider part, development of the essential function of device dependence absorption becomes easy.
Following is the framework of the CAO application.
1 A CAO application operates the device object abstracted by the CAO engine.
2 Based on the operation demand, the CAO engine executes the part of the process that doesn't depend on an actual device.
3 The CAO provider executes the part of the process that depends on the actual device and could not be processed by the CAO engine.

9
In general, " Program = algorithm + data ", and CAO is designed to unify the algorithm of the programs. Unifying application program strictly limits the program specifications, but unifying algorithm enables both generality and diversity of the program. In this way, resource data expression can be defined for each manufactures and models.
However, if the data expression is too much different, sharing the program becomes difficult. Therefore, ORiN introduced two ideas. One idea is system variables. Data generality can be improved by defining system variables whose meaning and purpose are laxly defined. Another idea is CAO model description language. Using the expression, a group of object necessary in assumed situations can be defined, and it is helpful to separate program algorithm and data.
Fi
gure5 shows the object tree of CAO. Because the architecture of CAO is separated to two layers (the engine part and the provider part), the object model is also separated in two.
The model of the provider part is a simple declaration model, and each object corresponds to the resource in controllers almost one by one. Please refer
File
Task （ job ）
File management
Expansion card
Controller （ main ）
Task
・ Language interpretation
Teach Box
Non-volatile resource
FA device
I/O Variabole
Robot management
Trajectory
Servo
Message
…
…
Command
PC
Volatile resource

10
‹
‹
Legend
Object
Collection
Simple model corresponding to controller resources
Both the engine part and the provider part only includes declaration model, and operation model is minimized.
Following is the reason why ORiN was designed in this way. For example, suppose resources like digital I/O. Its current value or attribute of input / output is included in declaration model. However, for the actual application programs, the model is not sufficient and various data acquisition method is necessary, like synchronous / asynchronous acquisition, or event generation when its value is changed. These methods and data processing are included in operation model.
On ORiN, these operational functions are designed to be provided on various gateway applications running on
CAO. ORiN is designed in this way because required operational functions so much depends on developed applications, and their variety is also very wide. Therefore, it is difficult that CAO engine include all necessary operational functions necessary in all types of applications. However, CAO engine exceptionally prepares asynchronous processing functions for CaoCommand class, because the class is naturally operational class for function expansion.
In addition, in controller abstraction for CAO, not all of the actual resources are mapped, but only their subset is mapped on the model. CAO collection is a subset of actual resources. In this way, even if the controller has so many numbers of resources, application program can access to it with realistic number of instances.
The CAO engine has general functions like object collection management, access limitation, message management,

11 and log management, etc. These functions are separated from interface specifications to some extent, and it is possible to expand these functions in the future as long as they conform the CAO interface specifications. Therefore, it is possible to implement the engine with different functions.
Because CAO is based on the distributed object technology, the module of CAO can be freely placed on the network. As a result, the object placement can be freely changed depending on the hardware configuration, software configuration, or CPU load, etc.
Currently available base technologies for distributed CAO module placement are DCOM of Microsoft, CORBA of
OMG, and SOAP of W3C. They can be selected according to the demanded performance and security.
Application
Process
PC
Application
CAO Engine
CAO Provider
PC
Application
Process
Application
Process
CAO
Proxy
CAO Engine Process
CAO
Provider
Provider
Proxy
Proprietary Protocol
DCOM，CORBA，CAP，e-CAP
Device
Resources
Surrogate Process
CAO
Provider
Resources
Device

12
CRD(Controller Resource Definition) is a standard to describe various, static resources of the FA device with
XML(Extensible Markup Language). The [de-tasuki-ma] is called CRD schema, and the XML file described according to this CRD schema is called CRD instance. CRD is standard [de-tasuki-ma] to manage information on the
FA device by a common format.
CRD assumes the following two usages and is designed. (Figure 5-1 Reference)
Definition of static data of device
Definition of configuration of device and the entire system
For instance, usage ① defines information "The length of robot A link 1 is 400mm". Such information need not communicate with the device because it is general and static, acquire, and only have to prepare the instance of CRD that stores the information on each device.
Information "Equipment consists of robot A, PLC B, and operating panel C" is defined as an example of usage ② .
The parameter to generate the instance of CAO(Controller Access Object) that the parameter and the device to communicate with each device offer can be stored in the CRD instance.
In the CRD schema, (..the design for each element of the CAO interface and CRD to relate closely... Figure
5-1).This is based on the design policy of ORiN to be able to use each specification (CAO,CRD,CAP) independently though concepts of the ORiN2 specification are united.
CAOエンジン
CaoEngine
CaoWorkspace
CaoController
CaoCommand
CaoExtension
CaoFile
CaoRobot
CaoTask
CaoVariable
CaoMessage
CAOプロバイダ
CaoProvController
CaoProvCommand
CaoProvExtension
CaoProvFile
CaoProvRobot
CaoProvTask
CaoProvVariable
CaoProvMessage
CRDタグ
<CRD>
<Controller> (1..*)
<Command> (0..*)
<Extension> (0..*)
<File> (0..*)
<Robot> (0..*)
<Task> (0..*)
<Variable> (0..*)
<Message> (0..*)
【 change point in CRD2.0 】
In CRD2.0 in addition to the above-mentioned two usages,
Capability definition of device
However. canIt has been enhanced as CRD2.0 to be more intuitively expressible though it was possible to express

13 by providing for the expression rule even in the CRD1.0 specification because the device capability is a content near usage ① . As for the instance of CRD1.0, because CRD2.0 is a complete upper compatibility of CRD1.0, the CRD2.0 schema is expressible.
It came to be able to define information "Variable I was able to be used for device A, and the range of the numerical value was 1-100" for instance more intuitively because of this enhancing.

14
CAP(Controller Access Protocol) is a protocol to achieve the remote access between objects by way of the Internet.
It communicates by using SOAP in CAP, and WSDL(Web Services Description Language) in the definition of service.
This is called CAP-WSDL.
It can access the CAO provider remotely by using DCOM of the CAO engine. However, the access through the
Internet cannot usually do the excess of the firewall that is impossible, and exists in the enterprise etc. on substance and the remote access with the restriction on security in DCOM. Then, CAP enabled the access through the Internet by using SOAP.
..CAP.. (..the design for the CAO interface and the interface of CAP to relate closely... Figure 6-1).This is based on the design policy of ORiN to be able to use each specification (CAO,CRD,CAP) independently though concepts of the ORiN2 specification are united.
CaoEngine
CaoWorkspace
CaoController
CaoCommand
CaoExtension
CaoFile
CaoRobot
CaoTask
CaoVariable
CaoMessage
CaoProvController
CaoProvCommand
CaoProvExtension
CaoProvFile
CaoProvRobot
CaoProvTask
CaoProvVariable
CaoProvMessage
<Controller_***>
<Command_***>
<Extension_***>
<File_***>
<Robot_***>
<Task_***>
<Variable_***>
<Message_***>

15
„ Distributed object technology
A software technology to deploy software components (objects) that operates based on common invocation rule, and build up system based on the cooperation of these objects. Distributed object technology includes DCOM, which is developed for Windows platform by Microsoft, CORBA defined by OMG, and JavaRMI used with Java language.
„ Interface
A substance or rule that intermediates two things to exchange information. On IT area, interface can be categorized in “Hardware Interface”, “Software Interface”, and “User Interface.”
„ XML (eXtensible Markup Language)
XML is a self-extensible markup language, and the designer of the document can decide the rule to decide the document structure. (This is a reason it is "self-extensible".) By utilizing the characteristics of document designer can freely define document structure, data based on XML standard but still not bound to specific structure and has high degree of freedom in data expression, can be widely exchanged.
XML has the following features.
・ Data form with meaning and content
・ Possible to define hierarchical data structure
・ Possible to describe tags logically, and to make up structured and easy-to-understand document.
・ Extensible and spreading as industry-standard data format.
„ DOM (Document Object Model)
DOM is standard API to treat the XML document as an object.
XML document itself is a text file, but applications like browser or CAO processes each element described in
XML as objects. If the way to handle XML as object is different between applications, it is big burden for developers. Therefore, W3C defined unified standard of DOM. XML API other than DOM is SAX(Simple API for XML), and both of them are widely used.
DOM defines several levels, and the larger level is newer and higher performance. The latest recommendation from W3C is Level-2, and CRD provider uses this level.
„
XML parser
The XML document usually exists as a text file. However, XML allows various expressions, and several procedures are necessary to read the data into application. XML parser is collection of commonly used procedures to read data.
A standardized API is used to call XML parser from application. Standard API includes DOM and SAX. DOM is an open standard and currently several XML parser based on DOM are released. For Windows environment,
MSXML can easily used with Visual C++ and Visual Basic, and CRD provider uses MSXML. There exists

16 several versions of MSXML, and CRD provider uses MSXML4.0. To use CRD provider, checking installed
MSXML version is necessary.
„ XML schema
The schema in XML is description of possible XML document structure. This is a description of correct arrangement of data element and attribute array, and by describing the schema, XML parser can check the correctness of XML document automatically to some extent.
Typical XML schema language includes DTD, XML Schema, RELAX, or XDR, and CRD uses XML Schema.
„ SOAP (Simple Object Access Protocol)
SOAP is a protocol to call the object on remote PC by transmitting messages described by XML format with
HTTP.
There are CORBA and DCOM, etc. as a technology to call the object on remote PC. However, these technologies use its original port number for communication. If communication over firewall is necessary, firewall need to be set to allow using the port. However, because there exists worms that uses DCOM security hole recently, communication to use DCOM port is usually not allowed.
To solve these problems, SOAP technology was developed. SOAP only defines message structure exchanged between object, and it uses existing HTTP and SMTP for communication protocol. As a result, if HTTP and
SMTP communication is possible, using distributed object technology through the firewall becomes possible by using SOAP.
„ WSDL (Web Services Description Language)
WSDL is an interface description language for XML based Web service. WSDL can describe Web service information like access point (URL), used protocol (SOAP, HTTP, MIME), message format (XML Schema). For
SOAP, WSDL file is equivalent to IDL (Interface Description Language) of CORBA and COM.
„ DCOM (Distributed Component Object Model)
Specification of distributed object technology defined by Microsoft Corp. The software parts crated based on
Microsoft COM specifications (called "COM object") communicate mutually through network, and they can exchange data or process request.
„
CORBA (Common Object Request Broker Architecture)
Specification of distributed object technology defined by OMG (OMG is an industry group for standardization and promotion of object-oriented technology, established in 1989). CORBA does not depend on a platform, while
DCOM is for the Windows platform.
„
CAO (Controller Access Object)
CAO is "Standard program interface" that offers a common interface and the function to the client application and controllers for FA (factory automation).

17
„ CAO interface (API)
A CAO provided API for client application to operate FA controllers. “CAO API” means this interface.
„ CAO engine
CAO engine is a middleware (executable) that implements CAO interface, and it provides common function to
CAO providers and CAO interface to CAO applications. Common functions for CAO provider are collection function, message output, CRD switching function, etc.
„ CAO provider
The CAO provider is subordinate module of CAO, and it is DLL that implements manufacture dependent process.
„ CAO provider template
C++ template that supports CAO Provider implementation. This template is automatically generated by
ProviderWizard.
„ CAP(Controller Access Protocol)
A "Communication protocol for the Internet" to access CAO provider over the Internet. In CAP, SOAP based messages to access the CAO provider is defined.
„ CAP provider
A CAO provider to generate, send and receive CAP message.
„ CAP listener
A server program to receive CAP message and run CAO on remote machine.
„ CAP message
A SOAP message defined by CAP.
„ CRD (Controller Resource Definition)
A data schema that defines general-purpose data format to express manufacture and model dependent resource information of FA equipment.
„
CRD resource
Resource of FA equipment expressed by CRD.
„
CRD data
FA equipment resource data described according to CRD and described by XML.

„ CRD data schema
A schema that defines the format of the CRD data.
„ CRD file
A XML file describing CRD data.
„ CRD provider
A kind of the CAO provider to access the CRD data.
18