BaSyx / Research / Component Meta Model
This page defines some basic concepts and meta models used in the BaSys project and the BaSyx software. It mainly deals with the defintion of the concept „component“ and different kinds of such components, like hardware components and software components. Additionally, “roles”, “realization units”, “composite components” and their relationships are defined by this page. For an overview over the types of Software components that are provided by the BaSyx software SDK, see BaSyx_/_Documentation.
The aim of this page is to provide an precisely defined vocabulary, which can be used in architectural discussions, studies and for modeling data structures in software components, such as submodels of asset administration shells.
- 1 Taxonomy of Components
- 2 Roles, Realization Units and Composite Components
- 3 Interfaces
- 4 References
Taxonomy of Components
In this section, a general taxnomy of different kinds of of components. An overview over the concepts and their relationships is presented in the figure.
Components are a common concept across many different fields of interest. According to the Cambridge Dictionary, a component is “a part that combines with other parts to form something bigger”. In the field of industrial automation, the word “component” typically refers to the concept of technical components.
This definition is based on the definition of “Technische Komponente” in the german DIN SPEC 40912 and the BaSys whitepaper D-PC2.4, yet augments it with the term “ may be handled as an independent unit during its period of usage”. Thus, all technical components (hardware and software) need to be able to be handled as an independent entity. Typically, this includes the identifiability, persistence and isolation of the component, the identifiability of external dependencies, and, in most cases, the compactness and disjointness of the component.
However, we only expect the component to fulfill these requirements during its usage period. It may for example be entangled with other components during development and production, but still be called a “component”.
“handling” a component includes all tasks required for setting up and using the component:
Software and Hardware Components
We further divide technical components into software components and hardware components
In this context, “software” is defined as follows:
This definition of software describes the physical manifestation of a piece of software, which should be distinguished from the concept of software as abstract information (as defined in the IEV for example).
Software components can only live on computer systems, which are a special kind of hardware components:
We use the term “smart component” for a special kind of hardware components
Integration of Components
Technical components may be aggregated, such that one or more components are integrated into another one with the following semantics:
A may still be handled independently in this relationship and may continue to exist without B. The integration of hardware components within each other is realized by installing them within the outer component, i.e. creating mechanical connections (bolting etc.) and connecting all required interfaces for material, energy, and information transport.
To integrate Software components into hardware components, they need to be stored in a memory of the the hardware component. Thus, the hardware component is required to be a computer system. In case that the software component is loaded dynamically at runtime, a reference to an external storage location of the component may also be considered as integration of that component.
Integrating software components into other software components is realized by composing the components into data structure to be collectively handled, e.g. by storing an executable file within the directory or archive of an outer component, by inserting a section into a structured file of the outer component, or by inserting (plugin) code at a designated memory location within the the memory range of the outer component.
The figure shows an example of some aggregated components from the BaSys 4.0 final demonstrator. For the example, we assume, the plant in the demonstrator simulation would have been physically constructed. Furthermore, we assume that each belt conveyors has an integrated PLC running the single control component for that conveyor, whereas the crane and the pick‘n‘place robots are controlled by a central computer running the ACPLT/RTE software.
All the components shown in the figure are concrete component instances (not types or roles – they are introduced below). The links between them represent physical integration: The belt conveyor‘s PLC is located within the belt conveyor; the robot control component RB-SCC V1.0 … is located at a defined memory location of the ACPLT/RTE database. As one can see in the figure, the crane‘s control component is not integrated wit the crane itself (in the sense of collective handling of the components).
Roles, Realization Units and Composite Components
In this section, the relation of components, component types and roles is presented, as well as the concept of composite components. Again, an overview of the concepts is shown in the figure.
To describe a set of equal components (same shape, size, functionality, interfaces, etc.) we define the “component type”:
Actual technical components are called instances of a component type. In practice, component types often exist before there are any components of that type: The are developed explicitly, resulting in different functional and mechanic plans as a basis for building the individual components. By contrast, in rare cases components are developed individually, such that they belong to their own unique type. For software components its possible (and common) that major parts of their functionality are only implemented once for the component type. Each single component needs to contain only the instance-specific data.
Roles & Functional Plans
Technical components, which are part of technical system (or integrated into another component), carry out different functions to make the overall system (resp. the outer component) work. This means that these functions fulfill tasks defined by the outer system, which we call “roles”:
A role defines the requirements for components to fulfill this role, especially for their capabilities and properties as well as for the kind and characteristics of their interfaces. Roles are typically defined by functional plans of a system or component type.
However, a functional plan does not actually contain the roles, since it is only an abstract document describing how the system or component will work, as soon as it has physically been constructed. Nevertheless, a plan describes all the requirements and properties that will later hold for the concrete roles. Thus, we call those descriptions “role templates”:
Role templates are abstract; i.e. they do not correspond to a concrete task to fulfill. For each realization implemented/built according to the plans (e.g. construction of a system that follows the plan) a role is created as an instance of each role template. These roles can be fulfilled by concrete components. For example, a given type of industrial robots (= component type) need to include a frequency inverter with certain specifications (= role template in the electrical plan of the robot type). When a robot of this type is manufactured, it requires an inverter with certain specifications according to the role template (= role); so a inverter (= component) is installed to fulfill this role.
Roles may also be defined by a greater context, e.g. based on management decisions in a company. In this case they are not necessarily an instance of a role template attached to a functional plan.
To fulfill a role, one or more technical components may be used. We call those components the “realization unit” of the role:
This is an abstract term: Components of a single realization set may be spread across different location and may not necessarily form a single component (that can be handled independently). Conversely, a component may be part of more than one realization units, if it fulfills different roles in the system.
Composite components are a special kind of aggregated components:
In other words, a composite component is a composition of components that itself forms a component, with the special property that the integrated components also play a functional role within the composite component.
Composite components may be hardware or software components. They may contain additional technical items that don‘t form components; i.e. not all parts of a composite component need to be a technical component. Composite components may or may not require to have all of their roles fulfilled (i.e. all designated places for components are filled with concrete components) to be functional.
From the example above we can now define realization units, independently from the aggregation of components. To fulfill the role “CR01”, which describes the function of a fully operational crane, a crane (in this case the crane Crane X01) and a corresponding single control component CR-SCC V1.0 on the central computer (which has been instantiated at memory location
0xdeadbeef) are required. Together, they form the realization unit of the role CR01.
The Belt Conveyor X01 forms a realization unit by itself, to fulfill the role of a belt conveyor in the plant. However, as a composite component, it provides additional roles that need to be fulfilled for the belt conveyor to work. The full model of types, roles and realization units for two belt conveyors is shown in the figure.
Both, Belt Conveyor X01 and Belt Conveyor X02, are of the same “Belt Conveyor Type”, which includes a “Control Architecture Plan”. This plan comprises two role templates to describe the roles for a single control component and a drive unit. Additionally, it may specify the data that will be interchanged between the two nodes and more details not shown in the figure. As instances of the Belt Conveyor Type, each of the two belt conveyors comprises a concrete role for each role template.
Belt Conveyor X02 has currently no PLC and no drive unit integrated into it, so there is no realization unit for both of its roles currently. In contrast, as shown above, Belt Conveyor X01 has a PLC with the required single control component and a drive unit integrated. The single control component forms the realization unit for the control component role; the drive unit forms the realization unit for the drive unit role.
Interfaces are the only possibility for a component to exchange matter/energy/information with its surrounding world. Software components may only have information interfaces.
Composite components may contain their own interfaces as integral part. Additionally, they may expose some of the interfaces of the integrated components.
The belt conveyor from the examples above has (at least) two interfaces: A power plug for energy transport and a digital service interface for receiving control commands (= information transport). Whilst the power plug is attached directly to the belt conveyor’s housing, the service interface is provided by the integrated single control component. Still, it’s exposed as an external interface by the belt conveyor.
- "component | meaning in the Cambridge English Dictionary". Retrieved December 18, 2019, from https://dictionary.cambridge.org/dictionary/english/component.
- "DIN SPEC 40912: Kernmodelle – Beschreibung und Beispiele". Berlin: DIN Deutsches Institut für Normung e. V. November 2014.
- Grothoff, Julian Alexander et al. (2018) "BaSys 4.0: Metamodell der Komponenten und Ihres Aufbaus". Aachen: RWTH Publications. DOI: 10.18154/RWTH-2018-225880. Retrieved December 18, 2019, from https://publications.rwth-aachen.de/record/728724/files/728724.pdf
- "IEC 60050-171: International Electrotechnical Vocabulary (IEV) – Part 171: Digital technology – Fundamental concepts". IEC International Electrotechnical Commission. March 2019.