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 "BaSyx / Documentation / ControlComponentProfiles"

(→‎Profile Meta Model: Adapted interface specification to VAB.)
m (→‎Interface Specification: Changed from item format to table for example. Changed OPERATIONS to a map property to conform to VAB type system.)
Line 52: Line 52:
 
This root element can be mapped to a specific control component instance by its elementId (e.g. URI or OPC UA node id).
 
This root element can be mapped to a specific control component instance by its elementId (e.g. URI or OPC UA node id).
 
Each element in the hierarchy needs to be specified by:
 
Each element in the hierarchy needs to be specified by:
−
* the name: browsename, path segment, ressource identifier, etc. depending on the technology.
+
* Name: browsename, path segment, ressource identifier, etc. depending on the technology.
−
* the element type: a property, property group or operation
+
* Element type: a property, property group or operation. (default: property)
−
* the modelling rule: mandatory or optional
+
* Modelling rule: mandatory or optional. (default: mandatory)
−
* optionally the requirement in a specific facet can be noted
+
* Requirement in a specific facet or facet group value range. May be combined via bool operators. (default: in all facets)
−
* Properties may be further specified by
+
* Properties may be further specified by:
−
** the datatype of VAB element based on the [[BaSyx_/_Documentation_/_VAB#Virtual_Automation_Bus_type_system|VAB type system]] and allowed values
+
** Datatype of VAB element based on the [[BaSyx_/_Documentation_/_VAB#Virtual_Automation_Bus_type_system|VAB type system]] and allowed values.
−
** the writeability of the property value (defaults to read only, if not specified)
+
** Writeability of the property value. (default: read only)
−
* Operations may be further specified by their input and output arguments via name and [[BaSyx_/_Documentation_/_VAB#Virtual_Automation_Bus_type_system|VAB data type]]
+
* Operations may be further specified by their input and output arguments via name and [[BaSyx_/_Documentation_/_VAB#Virtual_Automation_Bus_type_system|VAB data type]].
  
 
Hence, a simple and not normative example for an interface descpription may look like:
 
Hence, a simple and not normative example for an interface descpription may look like:
−
* VABElement: <ControlComponent>
+
{| class="wikitable"
−
** Group: STATUS, mandatory
+
! style="text-align:left;"| Relative Path
−
*** Property: EXST, String(EXECUTE|IDLE|...), mandatory, ES facet group > 1
+
! Name
−
*** Property: OCCUPIER, String, mandatory, OC facet group > 1
+
! Type
−
** Group: OPERATIONS, mandatory, SI facet 4:OPERATIONS
+
! Rule
−
*** Operation: START(), mandatory, ES facet group > 1
+
! Facets
−
*** Operation: HOLD(), optional, ES facet 2:BASYS
+
! Property Datatype
−
*** Operation: HOLD(), mandatory, ES facet 4:PACKML
+
<!--! Writeable
 +
! Operation Arguments -->
 +
|-
 +
|
 +
| STATUS
 +
| Property group
 +
| Mandatory
 +
|
 +
|
 +
|-
 +
| STATUS
 +
| EXST
 +
| Property
 +
| Mandatory
 +
| ES facet group > 1
 +
| String: EXECUTE/IDLE/...
 +
|-
 +
| STATUS
 +
| OCCUPIER
 +
| Property
 +
| Mandatory
 +
| OC facet group > 1
 +
| String
 +
|-
 +
|
 +
| OPERATIONS
 +
| Property
 +
| Mandatory
 +
| SI facet 4:OPERATIONS
 +
| Map<String, Operation>
 +
|-
 +
| OPERATIONS
 +
| START
 +
| Operation
 +
| Mandatory
 +
| ES facet group > 1 &<br/> SI facet 4:OPERATIONS
 +
|
 +
|-
 +
| OPERATIONS
 +
| HOLD
 +
| Operation
 +
| Optional
 +
| ES facet 2:BASYS &<br/> SI facet 4:OPERATIONS
 +
|
 +
|-
 +
| OPERATIONS
 +
| HOLD
 +
| Operation
 +
| Mandatory
 +
| ES facet 4:PACKML &<br/> SI facet 4:OPERATIONS
 +
|
 +
|}
 
An example for the minimum interface specification for basyx control components can be found in the [[BaSyx_/_Documentation_/_API_/_ControlComponent#Virtual_Automation_Bus_.28VAB.29_implementation|control component documentation]].
 
An example for the minimum interface specification for basyx control components can be found in the [[BaSyx_/_Documentation_/_API_/_ControlComponent#Virtual_Automation_Bus_.28VAB.29_implementation|control component documentation]].
 
<!--TODO discuss and update control component documentation-->
 
<!--TODO discuss and update control component documentation-->
Line 75: Line 126:
 
All interface specifications belong to the same namespace.
 
All interface specifications belong to the same namespace.
 
As control components may offer multiple facets combined in one interface, the name of each element in the hierarchy has to be non overlapping.
 
As control components may offer multiple facets combined in one interface, the name of each element in the hierarchy has to be non overlapping.
 +
Moreover, all names defined by BaSys should be written in uppercase to differentiate from application or domain specific variables and operations, e.g. specific operation modes.
 
<!--TODO update profile editor and create example figure-->
 
<!--TODO update profile editor and create example figure-->
  

Revision as of 12:55, 18 March 2020

Warning2.png
This information is work in progress as part of the BaSys 4.2 project. This section is preliminary and subject to change during the project.


Overview | Interface | Implementation

The abstract concept of control components and their state machines may be realised in technology specific ways or focuss on certain aspects. For example an occupation might not be necessary or a differentexecution state machine may be satisfying. Especially domain, task or company specific constraints need to be applied in brownfield scenarios. In order to describe basys control components in a standardized manner and to ensure the compliance of basys labled control components, possible realisations are described in facets and clustered in facet categories. These profiles or facets may be used for the typification und type description of control components. Furthermore, they can be used to define requirements of a component system or its orchestration environment.

One goal of BaSys 4.2 is to enable plug and produce scenarios via standardized procedures. Considering that, the requirements of heterogenous industrial production systems and the offered features of various control components needs to be described and matched. In order to support this matching in an automated manner a limitation to and standardization of usefull profiles is necessary. Combinations of commonly used facets will be used to define full featured profiles for easier commponent development and usage. Finally adapters may be generated to integrate components of different profiles.

In conclusion control component profiles describe which design patterns are used for a control component or its type in a standardized manner. Hence they are linked to the basys design patterns which rely on the control comopnent state machines. The goal is to reference existing standards and to build a bridge between component developers and their users. In the context of I4.0 it is recommended to use the control component submodel in the asset administrator shell (AAS) to describe required or assured profiles of a control component.

Profile Meta Model

In order to be technology agnostic the profile definition should rely on abstract concepts. Therefore a minimalistic meta model for control component profiles is defined here. The profile concept and terms are inspired by OPC UA Part 7[1].

A profile is a composition of facets describing the features or requirements of a control component. Each facet has a name and a numeric or bit value, like in an enumeration, which is related to the facet category. A facet category describes a specific aspect of the control component interface by grouping multiple facets. Usually a profile determines at least one facet for each facet category. Therefore the term profile is used synonymous to full featured profiles[1] here.

Interface Specification

Besides the facet and profile definition, the meta model is used to model the control components interface depending on the facets. This interface model may be converted to an OPC UA companion specificiation, an active AAS submodel or other information model technology standards. The interface specification is based on the BaSyx VAB, in order to describe the interface in a technology independent manner. Moreover, it is an important base to define conformance test units and derive test cases for automated compliance test.

A BaSyx interface specification for control componentes is structured as follows. The main definition is a VAB element hierarchy starting at the control component realization as root VAB element. This root element can be mapped to a specific control component instance by its elementId (e.g. URI or OPC UA node id). Each element in the hierarchy needs to be specified by:

  • Name: browsename, path segment, ressource identifier, etc. depending on the technology.
  • Element type: a property, property group or operation. (default: property)
  • Modelling rule: mandatory or optional. (default: mandatory)
  • Requirement in a specific facet or facet group value range. May be combined via bool operators. (default: in all facets)
  • Properties may be further specified by:
    • Datatype of VAB element based on the VAB type system and allowed values.
    • Writeability of the property value. (default: read only)
  • Operations may be further specified by their input and output arguments via name and VAB data type.

Hence, a simple and not normative example for an interface descpription may look like:

Relative Path Name Type Rule Facets Property Datatype
STATUS Property group Mandatory
STATUS EXST Property Mandatory ES facet group > 1 String: EXECUTE/IDLE/...
STATUS OCCUPIER Property Mandatory OC facet group > 1 String
OPERATIONS Property Mandatory SI facet 4:OPERATIONS Map<String, Operation>
OPERATIONS START Operation Mandatory ES facet group > 1 &
SI facet 4:OPERATIONS
OPERATIONS HOLD Operation Optional ES facet 2:BASYS &
SI facet 4:OPERATIONS
OPERATIONS HOLD Operation Mandatory ES facet 4:PACKML &
SI facet 4:OPERATIONS

An example for the minimum interface specification for basyx control components can be found in the control component documentation.

All interface specifications belong to the same namespace. As control components may offer multiple facets combined in one interface, the name of each element in the hierarchy has to be non overlapping. Moreover, all names defined by BaSys should be written in uppercase to differentiate from application or domain specific variables and operations, e.g. specific operation modes.

References

  1. ↑ 1.0 1.1 IEC 62541 Part 7 – OPC UA Profiles
BaSyx project links: Project BaSyx main wiki page | What is BaSyx? | BaSyx Developer Documentation
Retrieved from "https://wiki.eclipse.org/index.php?title=BaSyx_/_Documentation_/_ControlComponentProfiles&oldid=438717"

Back to the top