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.
Difference between revisions of "BaSyx / Documentation / ControlComponentProfiles"
(Adapted terms to OPC UA profiles after discussion with BaSys4.2 partners.) |
m (Renamed profile categories to facet categories for a better understanding and consitency. (profile category is used in OPC UA Part 7)) |
||
| Line 11: | Line 11: | ||
For example an [[BaSyx_/_Documentation_/_API_/_ControlComponent#Occupation state machine|occupation]] might not be necessary or a different[[BaSyx_/_Documentation_/_API_/_ControlComponent#Execution state state machine|execution state machine]] may be satisfying. | For example an [[BaSyx_/_Documentation_/_API_/_ControlComponent#Occupation state machine|occupation]] might not be necessary or a different[[BaSyx_/_Documentation_/_API_/_ControlComponent#Execution state state machine|execution state machine]] may be satisfying. | ||
Especially domain, task or company specific constraints need to be applied in brownfield scenarios. | 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 | + | 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. | 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. | Furthermore, they can be used to define requirements of a component system or its orchestration environment. | ||
| Line 37: | Line 37: | ||
A '''profile''' is a composition of '''facets''' describing the features or requirements of a control component. | 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, related to the | + | Each facet has a name and a numeric or bit value, like in an enumeration, related to the facet category. |
| − | A ''' | + | 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 | + | Usually a profile determines at least one facet for each facet category. |
Therefore the term profile is used synonymous to '''full featured profiles'''<ref name="OPCUA-Part7"/> here. | Therefore the term profile is used synonymous to '''full featured profiles'''<ref name="OPCUA-Part7"/> here. | ||
Revision as of 14:32, 19 February 2020
| 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, 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 Model
Besides the facet and profile definition, the meta model is used to model the control component interface depending on the facets. This interface model can be converted to an OPC UA companion specificiation, an active AAS submodel or other information model technology standards. Therefore the meta model is based on elements (nodes, ressources, etc.). These elements have a name (browsename, path, ressource identifier, etc.) and may contain facet requirements. A facet requirement names a facet and states whether it is optional or mandatory. Node sets, variables and methods are specialized elements:
- Node sets may contain other elements.
- A variable has a type of boolean, integer or string (or arrays of these types) and a flag if it is writeable.
- Methods may contain specialised variables called input or output parameter.
This simple meta model is sufficient to define the syntax and interfaces for all control component facets. It is an important base to define conformance test units and derive test cases for automated compliance test. It may easily be transfered to different information model technologies or communication protocols like OPC UA, REST, BaSyx VAB, etc. An example of the modeled interface is shown in the figure.
References
| BaSyx project links: Project BaSyx main wiki page | What is BaSyx? | BaSyx Developer Documentation |