Skip to main content
Jump to: navigation, search

BaSyx / Documentation / Component Meta Model

Warning2.png
This page is currently under work in progress. Not all concepts and definitions have already been verified with the relevant teams within the BaSys project. Please use the information provided by below with care. All definitions on this page will be added to the Glossary, as soon as they have been verified.


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.


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.

Taxonomy.png


Components

Components are a common concept across many different fields of interest. According to the Cambridge Dictionary[1], 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.

technical component
prefabricated entity with inner structure, that is designated to fulfill one or more roles within a technical system and may be handled as an independent unit during its period of usage

This definition is based on the definition of “Technische Komponente” in the german DIN SPEC 40912[2] and the BaSys whitepaper D-PC2.4[3], 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[3].

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:

to handle (a technical component)
to install, remove, change position of, configure, activate or deactivate one or more technical devices within a technical plant


Software and Hardware Components

We further divide technical components into software components and hardware components

hardware component
technical component composed of physical objects
software component
cohesive unit of software forming a technical component

In this context, “software” is defined as follows:

software
physical record of information (data) and algorithms in a computer system

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[4] for example).

Software components can only live on computer systems, which are a special kind of hardware components:

computer system
hardware component that contains parts for storing and executing software

We use the term “smart component” for a special kind of hardware components

smart component
hardware component that forms or contains a computer system, but has an additional main functionality, different from storing and executing software, and also contains all required software components to provide a service-based interface to the main functionality


Integration of Components

Technical components may be aggregated, such that one or more components are integrated into another one with the following semantics:

to integrate (a component) into
to link a component A with another component B in such a way that, henceforth, A is contained in B and will be handled as unit collectively with B

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.


Example

ExampleAggregations.png

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.

Type-Instance-Role.png


Component Types

To describe a set of equal components (same shape, size, functionality, interfaces, etc.) we define the “component type”:

component type
abstract description of set of equal components

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”:

role
unambiguously described task/purpose within a greater context

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.

functional plan
document or data structure that specifies the roles to be fulfilled in a technical system or technical components of a certain type and describes their relationships from the point of view of a particular craft/domain

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 template
Description of a role in a functional plan

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.


Realization Units

To fulfill a role, one or more technical components may be used. We call those components the “realization unit” of the role:

realization unit
Set of all components that fulfill a role at a given point in time

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

Composite components are a special kind of aggregated components:

composite component
technical component that comprises one or more roles for additional components, which require the fulfilling components to be integrated into the composite component

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.


Example

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.

ExampleCraneRealization.png

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.

ExampleConveyorRealization.png

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

Interfaces.png

Interface
item within a component that enables the component to exchange matter, energy, and/or information with the surrounding system or other components, while specifying the form and properties of the matter/energy/information as well as the technical properties of that item as accurate as required

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.


Example

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.

ExampleConveyorInterfaces.png


References

  1. "component | meaning in the Cambridge English Dictionary". Retrieved December 18, 2019, from https://dictionary.cambridge.org/dictionary/english/component.
  2. "DIN SPEC 40912: Kernmodelle – Beschreibung und Beispiele". Berlin: DIN Deutsches Institut für Normung e. V. November 2014.
  3. 3.0 3.1 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
  4. "IEC 60050-171: International Electrotechnical Vocabulary (IEV) – Part 171: Digital technology – Fundamental concepts". IEC International Electrotechnical Commission. March 2019.

Back to the top