The coordination of software components at run-time and the run-time management of the component's internal resources are fundamentally important for designing robust and efficient systems. Therefore, RobMoSys specifies a generic component lifecycle that can be extended by component-specific operation modes (see the technical report below for further technical details).

The component lifecycle (see figure on the right) is a generic state automaton that every component has by default and that manages the initialization, shutdown and operation of a component in a uniform way. This lifecycle does not require a detailed metamodel as it is the same for every component and thus is an implicit part of the Component-Definition Metamodel (see the “Lifecycle” element in the component metamodel). The lifecycle is defined here:

• Christian Schlegel, Alex Lotz and Andreas Steck, “SmartSoft - The State Management of a Component”, in Technical Report 2011/01, Hochschule Ulm, Germany, ISSN 1868-3452, 2011. PDF

Moreover, every component can specify individual operation modes (see Component Development View) which can be dynamically (de-)activated at run-time to manage the component's internal activities and thus the component's functional resource consumption. There is an interesting relation between the component's operation modes, services and functions. The component's operation modes interface between the component's internal functions (implemented within relevant activities) and the component's services. Each operating mode activates related activities and thus functions. As activities are responsible for generating data for related services, activating a certain operating mode indirectly activates respective services. Deactivating a certain operation mode means that one or several related activities are deactivated (i.e., each deactivated activity stops before its next execution cycle until this activity gets activated again). This is a uniform mechanism to dynamically manage the component's resources at run-time in a consistent way without violating the component's internal implementation.

Overall, the management of the component's lifecycle and the management of the component's operation modes is an important part of the component's coordination interface (see Coordination and Configuration Patterns). Several robotic frameworks such as SmartSoft and RT-Middleware support this component lifecycle directly and other frameworks such as ROS are currently working on the implementation of a similar component lifecyle under the term Managed nodes.

The Gazebo/TIAGo/SmartSoft Scenario consists of several components each implementing at least the generic component lifecycle as described above. This already allows coordinated startup (i.e., initialization) and shutdown (i.e., destruction) of these components. During regular operation, each component at least has two regular opertion modes:

• Neutral: all the component's internal activities are in a standby state
• Active: all the component's internal activities are activated and operational

At runtime, only one of these modes can be active at a time and switching between them is possible at any time. The Neutral mode is reserved for the inactive (i.e., passive) state of a component. This means that a component might by fully started and ready to deliver a service but is within a standby mode and does not consume its specific resources. Switching into the Active mode means that the component wakes up an continuously delivers its service(s). These two modes are the default operation modes of a component which covers the majority of all use-cases.

In some cases, it is reasonable to have a more detailed definition of the Active mode (i.e., if a component can have several partial activation of its internal functionalities). For example, the component “SmartMapperGridMap” from the Gazebo/TIAGo/SmartSoft Scenario provides two main functionalities, namely to build long-term maps and update local grid maps. For coordinating these two functionalities, this component provides (besides of the default “Neutral” mode) the following three operation modes (instead of the generic “Active” mode):

• BuildCurrMap: for updating only the current (local) map
• BuildLtmMap: for building the long-term map
• BuildBothMaps: for building and updating both maps (highest resource demands)

These modes enable the robot to dynamically coordinate the amount of resources a component consumes depending on the current situation and the task a robot is performing. Switching into the Neutral mode is always possible for each component in situations where this component is not used in a system. In this way, it is not necessary to completely kill a component (if currently not needed) and start it again (if needed again) which is typically more time-consuming than just switching between respective component's operation modes.

Concrete models for these component examples are presented and discussed in the Example for Coordinating Activities and Life Cycle of Software Components using the SmartMDSD Toolchain.

• Component Development View
• Component-Definition Metamodel

The operation mode in the component-definition metamodel is modeled via the lifecycle metamodel which is yet to be described.

The following page demonstrates how concrete operating modes are modeled in existing navigation components using the SmartMDSD Toolchain: Example for Coordinating Activities and Life Cycle of Software Components using the SmartMDSD Toolchain