The System Service Architecture Metamodel is a particularly useful meta-model for System Architects. This meta-model allows the definition of service-based reference architectures for specific (sub-)domains on Tier 2. This meta-model depends on service-definitions and itself can be used to check “conformance” of a system-component-architecture to this service-based reference architecture. Checking this conformance is one of the main concerns of the service-fulfillment meta-model (see the following section below).

The System Service Architecture Metamodel specifies service-wishes which are component-independent definitions of service-requirements for a set of systems. Moreover, links between service-wishes specify component-independent inter-service dependencies (i.e. a service-wish might depend on the existence of another service-wish).

For example, a set of recurring services for a navigation stack (such as localization, mapping, path-planning, obstacle-avoidance, etc.) can be specified in advance independent of a concrete system and independent of concrete implementations in software components. In addition, it can be specified that a path-planning service typically depends on the existence of a localization service which itself depends on a mapping service, etc.

In addition, a service-wish can instantiate several service-properties which allow definition of specific Quality-of-Service (QoS) attributes. Examples for such attributes can be found here.

Please note, that the definition of service-based reference architectures seldom defines all services of one concrete system. Instead, a service-based reference architectures typically defines only the recurring services for (or from) a set of systems.

The Service Fulfillment Metamodel maps the service-wishes from a system-service-architecture (see above) with the provided-service-instances from a system-component-architecture. This mapping of service-wishes to provided-service-instances is called service-fulfillment. This is a powerful meta-model that allows definition of domain-specific de-facto standard architecture and thus considerably increases reuse of recurring specifications and at the same time fosters competition on implementation level (conforming to modeled reference architectures).

While the Service Fulfillment Metamodel directly depends on the two meta-models “System Service Architecture” (see above) and “System Component Architecture”, the order of usage of these two models is not strict. For instance, an existing (i.e. fully specified) system-component-architecture can be used to check whether it conforms to a later (or independently) defined system-service-architecture. Or, a specified system-service-architecture can be used upfront to select conforming components (from a component repository) for a current (i.e. new) system-component-architecture under development. Of course, all the intermediate options are also possible with partial specifications of system-service-architectures and system-component-architectures with intermediate checking of conformance.

An interesting option for this meta-model is to use constraint solvers to automatically pre-select existing component-definitions from a component repository according to the specified system-service-architecture. This is a powerful mechanism that considerably improves efficiency in designing new systems.

See next:

• System Component Architecture Metamodel

See also:

• Service-Definition Metamodel

This document contains material from:

• Stampfer2017 Dennis Stampfer, “Contributions to Composability using a System Design Process driven by Service Definitions for Service Robotics,” 2017. (unpublished work)
• Lotz2017 Alex Lotz, “Managing Non-Functional Communication Aspects in the Entire Life-Cycle of a Component-Based Robotic Software System,” 2017. (unpublished work)
• Lutz2017 Matthias Lutz, “Model-Driven Behavior Development for Service Robotic Systems: Bridging the Gap between Software- and Behavior-Models,” 2017. (unpublished work)