Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Talk:BaSyx / Documentation / API / ControlComponent"

(Suggested Control component interface harmonization)
 
m (Small improvements to the description.)
Line 1: Line 1:
 
= Control component interface harmonization =
 
= Control component interface harmonization =
  
Lets try to harmonize existing implementations of control components and sync to the 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 are suggested:
* Delete 'service' path segment for list of operations
+
* 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.
 
* Use uppercase paths to distinguish between user specific and standardized elements.
 
* Use uppercase paths to distinguish between user specific and standardized elements.
* Focus on the OPERATIONS profile as minimum requirement.
+
* Focus on the OPERATIONS service interface.
* Focus on 'mandatory' attributes
+
* Focus on 'mandatory' attributes.
 +
* Delete BSTATE as mandatory operation mode.
 
* Delete signals for localOverwrite and localOverwriteFree as they are technology specific and should be 'hard wired'.
 
* Delete signals for localOverwrite and localOverwriteFree as they are technology specific and should be 'hard wired'.
* Use network layer authorization to occupy component (no senderId parameter for operations, otherwise all operations need a senderId parameter)
+
* Use network layer authorization to occupy component (no senderId parameter for operations, otherwise all operations need a senderId parameter).
 
* OPC UA mapping:
 
* OPC UA mapping:
 
** 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 facets are required minimum?
+
* Which [[BaSyx_/_Documentation_/_API_/_ControlComponentProfiles#Facets|facets]] should form the BASYS profile?
 
** Possible:
 
** Possible:
 +
*** SI: CMD, OPERATIONS, SERVICES
 
*** OC: NONE, OCCUPIED, PRIO
 
*** OC: NONE, OCCUPIED, PRIO
 
*** EM: NONE, AUTO, SEMIAUTO, MANUAL, SIMULATE
 
*** EM: NONE, AUTO, SEMIAUTO, MANUAL, SIMULATE
 
*** ES: Minimum / full PackML
 
*** ES: Minimum / full PackML
*** OM: BSTATE
+
*** OM: NONE / MULTI /PARALLEL
 
** Suggested:
 
** Suggested:
 +
*** SI: OPERATIONS
 
*** OC: OCCUPIED, PRIO
 
*** OC: OCCUPIED, PRIO
 
*** EM: AUTO, MANUAL
 
*** EM: AUTO, MANUAL
*** ES: Minimum PackML (Start, Stop, Reset, Abort and corresponding states)
+
*** ES: Minimum PackML (START, STOP, RESET, ABORT and corresponding states)
*** OM: BSTATE
+
*** OM: MULTI
 +
 
 +
The following sections are adapted to the suggested changes above.
  
 
== Virtual Automation Bus (VAB) implementation ==
 
== Virtual Automation Bus (VAB) implementation ==
Line 105: Line 111:
 
| Execution mode
 
| Execution mode
 
| Clear aborted execution state
 
| Clear aborted execution state
|-
 
| OPERATIONS/BSTATE
 
| Operation mode
 
| Reset the operation mode to basic state
 
 
|}
 
|}
  
Line 119: Line 121:
 
==== OPC-UA ====
 
==== OPC-UA ====
  
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 BaSys 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. The namespace index of all browse names should be the basys namespace ''basys40.de''.
+
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. The namespace index of all browse names should be the basys namespace ''basys40.de''.
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 154: Line 156:
 
| String
 
| String
 
|-
 
|-
| STATUS/FREE
+
| OPERATIONS/FREE
 
| Method
 
| Method
 
|  
 
|  
 
|-
 
|-
| STATUS/OCCUPY
+
| OPERATIONS/OCCUPY
 
| Method
 
| Method
 
|  
 
|  
 
|-
 
|-
| STATUS/PRIO
+
| OPERATIONS/PRIO
 
| Method
 
| Method
 
|  
 
|  
 
|-
 
|-
| STATUS/AUTO
+
| OPERATIONS/AUTO
 
| Method
 
| Method
 
|  
 
|  
 
|-
 
|-
| STATUS/MANUAL
+
| OPERATIONS/MANUAL
 
| Method
 
| Method
 
|  
 
|  
 
|-
 
|-
| STATUS/START
+
| OPERATIONS/START
 
| Method
 
| Method
 
|  
 
|  
 
|-
 
|-
| STATUS/RESET
+
| OPERATIONS/RESET
 
| Method
 
| Method
 
|  
 
|  
 
|-
 
|-
| STATUS/ABORT
+
| OPERATIONS/ABORT
 
| Method
 
| Method
 
|  
 
|  
 
|-
 
|-
| STATUS/STOP
+
| OPERATIONS/STOP
 
| Method
 
| Method
 
|  
 
|  
 
|-
 
|-
| STATUS/CLEAR
+
| OPERATIONS/CLEAR
| Method
+
|
+
|-
+
| STATUS/BSTATE
+
 
| Method
 
| Method
 
|  
 
|  

Revision as of 09:22, 16 March 2020

Control component interface harmonization

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 are suggested:

  • 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.
  • Use uppercase paths to distinguish between user specific and standardized elements.
  • Focus on the OPERATIONS service interface.
  • Focus on 'mandatory' attributes.
  • Delete BSTATE as mandatory operation mode.
  • Delete signals for localOverwrite and localOverwriteFree as they are technology specific and should be 'hard wired'.
  • Use network layer authorization to occupy component (no senderId parameter for operations, otherwise all operations need a senderId parameter).
  • OPC UA mapping:
    • 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
  • Which 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.

Attribute path (output) Corresponding state machine Description
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
Operations Corresponding state machine Description
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

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. The namespace index of all browse names should be the basys namespace basys40.de.

Relative OPC-UA browse path Node class Data type
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/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.

Back to the top