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"
(Moved profile sections from BaSyx_/_Documentation_/_API_/_ControlComponent) |
(Added profile meta model description and example figure.) |
||
| Line 8: | Line 8: | ||
|} | |} | ||
| − | The abstract concept of [[BaSyx_Control_Components|control components]] and their [[BaSyx_/_Documentation_/_API_/_ControlComponent#Control component state machines|state machines]] may be realised in technology specific ways or | + | The abstract concept of [[BaSyx_Control_Components|control components]] and their [[BaSyx_/_Documentation_/_API_/_ControlComponent#Control component state machines|state machines]] may be realised in technology specific ways or focuss on certain aspects. |
For example an [[BaSyx_/_Documentation_/_API_/_ControlComponent#Occupation state machine|occupation]] might not be necessary or a smaller [[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 smaller [[BaSyx_/_Documentation_/_API_/_ControlComponent#Execution state state machine|execution state machine]] may be satisfying. | ||
Especially domain, task or company specific constraints may need to be applied in brownfield scenarios. | Especially domain, task or company specific constraints may need to be applied in brownfield scenarios. | ||
| Line 16: | Line 16: | ||
One goal of ''BaSys 4.2'' is to enable plug and produce scenarios via standardized procedures. | 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 | + | 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 and standardization | + | In order to support this matching in an automated manner a limitation to and standardization of usefull profiles is necessary. |
Combinations of commonly used profiles will be used to define integration variants for easier commponent development and usage. | Combinations of commonly used profiles will be used to define integration variants for easier commponent development and usage. | ||
Finally adapters may be generated to integrate components of different profiles. | Finally adapters may be generated to integrate components of different profiles. | ||
| Line 27: | Line 27: | ||
<!-- TODO Create and link wiki article for control component submodel --> | <!-- TODO Create and link wiki article for control component submodel --> | ||
| − | |||
== Profile Meta Model == | == Profile Meta Model == | ||
| − | - | + | |
| − | - | + | [[File:BaSyx-ControlComponentProfiles-profile-meta-model-example.png|thumb|Example of the profile definitions in the profile meta model.]] |
| − | + | <!--TODO maybe add the meta model as class model itself --> | |
| − | -- | + | A profile describes a specific aspect of the control component interface by multiple profile values. |
| + | 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. | ||
| + | |||
| + | Each profile value has a name and a numeric value, like in an enumeration. | ||
| + | The meta model is based on elements (nodes, ressources, etc.). | ||
| + | These elements have a name (browsename, path, ressource identifier, etc.) and may contain profile requirements. | ||
| + | A profile requirement names a profile value and states whether it is optional or mandatory in this profile. | ||
| + | Node sets, variables and methods are special 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 or interfaces for all control component profiles and derive test cases. | ||
| + | It may easily be transfered to different information model technologies or communication protocols like OPC UA, REST, BaSyx VAB, etc. | ||
| + | An example of the profile definitions is shown in the [[:File:BaSyx-ControlComponentProfiles-profile-meta-model-example.png|figure]]. | ||
Revision as of 12:07, 22 January 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 smaller execution state machine may be satisfying. Especially domain, task or company specific constraints may 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 realisation types are clustered in profiles. These profiles 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 profiles will be used to define integration variants 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 creators 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
A profile describes a specific aspect of the control component interface by multiple profile values. 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.
Each profile value has a name and a numeric value, like in an enumeration. The meta model is based on elements (nodes, ressources, etc.). These elements have a name (browsename, path, ressource identifier, etc.) and may contain profile requirements. A profile requirement names a profile value and states whether it is optional or mandatory in this profile. Node sets, variables and methods are special 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 or interfaces for all control component profiles and derive test cases. It may easily be transfered to different information model technologies or communication protocols like OPC UA, REST, BaSyx VAB, etc. An example of the profile definitions is shown in the figure.