|
|
| Line 2: |
Line 2: |
| | | | |
| | Lets try to harmonize existing implementations of control components and sync to the [[BaSyx_/_Documentation_/_API_/_ControlComponentProfiles|control component profiles]], which are used to test conformance. | | Lets try to harmonize existing implementations of control components and sync to the [[BaSyx_/_Documentation_/_API_/_ControlComponentProfiles|control component profiles]], which are used to test conformance. |
| − | The following changes to the [[BaSyx_/_Documentation_/_API_/_ControlComponent#Virtual_Automation_Bus_.28VAB.29_implementation|VAB implmentation]] documentation of control components are suggested: | + | The following changes to the [[BaSyx_/_Documentation_/_API_/_ControlComponent#Virtual_Automation_Bus_.28VAB.29_implementation|VAB implmentation]] documentation of control components were made in commit [https://wiki.eclipse.org/index.php?title=BaSyx_/_Documentation_/_API_/_ControlComponent&oldid=440375 440375]: |
| | * Only define a 'default' BaSyx VAB implementation (not 'minimum' required) as different requirements apply for different use cases. | | * Only define a 'default' BaSyx VAB implementation (not 'minimum' required) as different requirements apply for different use cases. |
| | * Delete 'service' path segment for list of operations. | | * Delete 'service' path segment for list of operations. |
| Line 14: |
Line 14: |
| | ** Delete ''Control'' path segment for the OPC UA browse path | | ** Delete ''Control'' path segment for the OPC UA browse path |
| | ** Add a namespace for basys that can be used to translate the browsepath and to for companion specifications later: basys40.de | | ** Add a namespace for basys that can be used to translate the browsepath and to for companion specifications later: basys40.de |
| − |
| |
| − | * Which [[BaSyx_/_Documentation_/_API_/_ControlComponentProfiles#Facets|facets]] should form the BASYS profile?
| |
| − | ** Possible:
| |
| − | *** SI: CMD, OPERATIONS, SERVICES
| |
| − | *** OC: NONE, OCCUPIED, PRIO
| |
| − | *** EM: NONE, AUTO, SEMIAUTO, MANUAL, SIMULATE
| |
| − | *** ES: Minimum / full PackML
| |
| − | *** OM: NONE / MULTI /PARALLEL
| |
| − | ** Suggested:
| |
| − | *** SI: OPERATIONS
| |
| − | *** OC: OCCUPIED, PRIO
| |
| − | *** EM: AUTO, MANUAL
| |
| − | *** ES: Minimum PackML (START, STOP, RESET, ABORT and corresponding states)
| |
| − | *** OM: MULTI
| |
| − |
| |
| − | The following sections are adapted to the suggested changes above.
| |
| − |
| |
| − | == Virtual Automation Bus (VAB) implementation ==
| |
| − |
| |
| − | Eclipse BaSyx connects BaSyx control components as elements to the Virtual Automation Bus (VAB), the End-to-End communication infrastructure of Eclipse BaSyx. Every BaSyx control component needs to implement the '''minimum VAB interface''' that is described in this section. The following table illustrates the minimum set of VAB attributes and operations for control components that are connected to the virtual automation bus. The predefined property group ''STATUS'' lists all propertys describing the current status of the control component, respectively its state machine states. The predefined ''OPERATIONS'' group implement the minimum API for every control component that enables the control of its states via the previously described state machines.
| |
| − |
| |
| − | {| class="wikitable"
| |
| − | ! style="text-align:left;"| Attribute path (output)
| |
| − | ! Corresponding state machine
| |
| − | ! Description
| |
| − | |-
| |
| − | | STATUS
| |
| − | |
| |
| − | | Property group for all status properties
| |
| − | |-
| |
| − | | STATUS/OCCST
| |
| − | | Occupation
| |
| − | | Current occupation state
| |
| − | |-
| |
| − | | STATUS/OCCUPIER
| |
| − | | Occupation
| |
| − | | ID of current occupier
| |
| − | |-
| |
| − | | STATUS/EXMODE
| |
| − | | Execution mode
| |
| − | | Active execution mode
| |
| − | |-
| |
| − | | STATUS/EXST
| |
| − | | Execution state
| |
| − | | Active execution state
| |
| − | |-
| |
| − | | STATUS/OPMODE
| |
| − | | Operation mode
| |
| − | | Active operation mode
| |
| − | |-
| |
| − | | STATUS/WORKST
| |
| − | | Work state
| |
| − | | Current work state
| |
| − | |-
| |
| − | | STATUS/ER
| |
| − | | Error state
| |
| − | | Current error state
| |
| − | |-
| |
| − | ! style="text-align:left;"| Operations
| |
| − | ! Corresponding state machine
| |
| − | ! Description
| |
| − | |-
| |
| − | | OPERATIONS
| |
| − | |
| |
| − | | Group for all operations
| |
| − | |-
| |
| − | | OPERATIONS/FREE
| |
| − | | Occupation
| |
| − | | Free component occupation if sender is occupier
| |
| − | |-
| |
| − | | OPERATIONS/OCCUPY
| |
| − | | Occupation
| |
| − | | Occupy component
| |
| − | |-
| |
| − | | OPERATIONS/PRIO
| |
| − | | Occupation
| |
| − | | Occupy component with priority
| |
| − | |-
| |
| − | | OPERATIONS/AUTO
| |
| − | | Execution mode
| |
| − | | Change to execution mode AUTO
| |
| − | |-
| |
| − | | OPERATIONS/MANUAL
| |
| − | | Execution mode
| |
| − | | Change to execution mode MANUAL
| |
| − | |-
| |
| − | | OPERATIONS/START
| |
| − | | Execution mode
| |
| − | | Start selected operation mode
| |
| − | |-
| |
| − | | OPERATIONS/RESET
| |
| − | | Execution mode
| |
| − | | Reset completed or stopped control component
| |
| − | |-
| |
| − | | OPERATIONS/ABORT
| |
| − | | Execution mode
| |
| − | | Abort operation
| |
| − | |-
| |
| − | | OPERATIONS/STOP
| |
| − | | Execution mode
| |
| − | | Stop operation
| |
| − | |-
| |
| − | | OPERATIONS/CLEAR
| |
| − | | Execution mode
| |
| − | | Clear aborted execution state
| |
| − | |}
| |
| − |
| |
| − |
| |
| − | === Technology mappings ===
| |
| − |
| |
| − | The BaSys 4.0 project has defined technology mappings for the device interface that are implemented by the Virtual Automation bus. BaSyx users may define additional technology mappings for other types of networks and bus systems, and include them by creating BaSyx Virtual Automation Bus (VAB) Gateways.
| |
| − |
| |
| − | ==== OPC-UA ====
| |
| − |
| |
| − | [[File:BaSyx-ControlComponent-OPCUA-BaSysProfile.png|thumb|An example control component in OPC UA realizing the BASYS profile. The control components address space is marked in orange.]]
| |
| − | This section defines a mapping of the BaSys 4.0 control component interface to OPC-UA. Our OPC-UA mapping maps VAB operations to OPC-UA methods and VAB attributes to OPC-UA variables, resprectively properties. Eclipse BaSyx will provide a generic BaSyx OPC-UA gateway component to connect control components with the OPC-UA interface from this section to the virtual automation bus and therefore enables accessing of the control component status and services. Developers therefore only need to implement this OPC-UA object structure to ensure a BaSyx conforming component. The control components browsename itself is not relevant as it is identified by its node id corresponding to the VAB elementId, shown in green in the [[:File:BaSyx-ControlComponent-OPCUA-BaSysProfile.png|example figure]]. The namespace index of all browse names defined here, should be the basys namespace ''basys40.de'', which is namespace 2 in the [[:File:BaSyx-ControlComponent-OPCUA-BaSysProfile.png|example figure]]. Operations to select application or domain specific operation modes should be written in CamelCase and should use own namespaces or the application namespace.
| |
| − | For the interface only the minimum required characteristics are describe in order to gain as much freedom of implementation as possible (cf. [[BaSyx_/_Documentation_/_ControlComponentProfiles#Interface_Specification|interface specification]]).
| |
| − | Hence only the entry point (VAB elementId, OPC UA node id of the control component) and browsepathes are specified, as shown in the blue field in the [[:File:BaSyx-ControlComponent-OPCUA-BaSysProfile.png|example figure]].
| |
| − | For example no display names, descriptions, node ids, type references or reference types for the hierarchical references are specified.
| |
| − |
| |
| − | {| class="wikitable"
| |
| − | ! style="text-align:left;"| Relative OPC-UA browse path
| |
| − | ! Node class
| |
| − | ! Data type
| |
| − | |-
| |
| − | | STATUS
| |
| − | | Object or Variable
| |
| − | | Group for all status variables
| |
| − | |-
| |
| − | | STATUS/OCCST
| |
| − | | Variable
| |
| − | | String
| |
| − | |-
| |
| − | | STATUS/OCCUPIER
| |
| − | | Variable
| |
| − | | String
| |
| − | |-
| |
| − | | STATUS/EXMODE
| |
| − | | Variable
| |
| − | | String
| |
| − | |-
| |
| − | | STATUS/EXST
| |
| − | | Variable
| |
| − | | String
| |
| − | |-
| |
| − | | STATUS/OPMODE
| |
| − | | Variable
| |
| − | | String
| |
| − | |-
| |
| − | | STATUS/WORKST
| |
| − | | Variable
| |
| − | | String
| |
| − | |-
| |
| − | | STATUS/ER
| |
| − | | Variable
| |
| − | | String
| |
| − | |-
| |
| − | | OPERATIONS
| |
| − | | Object or Variable
| |
| − | | Group for all operations
| |
| − | |-
| |
| − | | OPERATIONS/FREE
| |
| − | | Method
| |
| − | |
| |
| − | |-
| |
| − | | OPERATIONS/OCCUPY
| |
| − | | Method
| |
| − | |
| |
| − | |-
| |
| − | | OPERATIONS/PRIO
| |
| − | | Method
| |
| − | |
| |
| − | |-
| |
| − | | OPERATIONS/AUTO
| |
| − | | Method
| |
| − | |
| |
| − | |-
| |
| − | | OPERATIONS/MANUAL
| |
| − | | Method
| |
| − | |
| |
| − | |-
| |
| − | | OPERATIONS/START
| |
| − | | Method
| |
| − | |
| |
| − | |-
| |
| − | | OPERATIONS/RESET
| |
| − | | Method
| |
| − | |
| |
| − | |-
| |
| − | | OPERATIONS/ABORT
| |
| − | | Method
| |
| − | |
| |
| − | |-
| |
| − | | OPERATIONS/STOP
| |
| − | | Method
| |
| − | |
| |
| − | |-
| |
| − | | OPERATIONS/CLEAR
| |
| − | | Method
| |
| − | |
| |
| − | |}
| |
| − |
| |
| − | Additional gateways may implement additional mapping schemes, and may include control components and devices with non-conforming interfaces by implementing component and device specific mappings that provide a conforming façade to the VAB.
| |
Lets try to harmonize existing implementations of control components and sync to the control component profiles, which are used to test conformance.
The following changes to the VAB implmentation documentation of control components were made in commit 440375:
