eC3M Component Model (FCM)

• Instead of a certain number of fixed port kinds (Facet, Receptacle, Event publish/consumer and streaming), FCM proposes an extensible mechanism: an FCM port is characterized by its kind (defined in a model library) and its type. Each port kind implies a certain semantics (not formally defined) and specifies mapping rules which define how a port type is represented in terms of provided and required interfaces. A publishing port typed with a data type is for instance represented by a required (used) interface which contains a push method. The extensible port kinds generalize specific mapping rules of the CCM core specification. The main motivation was that the existing mapping is often inadequate for embedded systems, e.g. control systems want to receive events via polling (within a period task) instead of being called by a middleware thread.
• Interaction styles and their implementation are defined by connectors Connectors are first class citizens that are like components: connectors have ports and there is a distinction between type and implementations. The latter is important as it allows choosing a realization of an interaction at deployment time. In particular, it is possible to use CCM without requiring an ORB. In embedded systems, other transports (including direct communication) are often more suitable, since their footprint is considerably smaller. Connector types (and thus their implementations) do often depend on a template parameter which allows adapting a connector to its context, i.e. to bind interfaces of the connector ports to those used by the component ports.
• Lightweight containers for static deployment. These containers do not implement the standard CCM interfaces Navigation and Receptacles, since they are only called locally by a “bootloader” which performs instantiation and configuration of components on a node. This can reduce the footprint of the component based application considerably.