Embedded Systems Modeling Language
Sandeep Neema, Arpad Bakay, Gabor Karsai
Institute of Software Integrated Systems, Vanderbilt University
{neemask,arpad,gabor}@vuse.vanderbilt.edu
This document introduces the Embedded Systems Modeling Language (ESML), a
domain-specific graphical modeling language developed for modeling Real-Time
Mission Computing Embedded Avionics applications. The reader of this document is
expected to be familiar with the concepts of domain-specific graphical modeling, and its
instantiation in the Model Integrated Computing (MIC) framework developed at ISIS,
Vanderbilt University (for terminology and details see [1]).
The ESML is specifically intended for modeling component-based avionics applications
designed for the Bold-Stroke [2] component deployment and distribution middleware
infrastructure. The infrastructure implements an event-driven model of computation. In
this model of computation supplier components notify other component of the
availability of data through events. Consumer components interested in the data of the
suppliers get notified when they subscribe to these events. An event-channel service
implemented by the infrastructure facilitates event filtering, propagation and notification.
The real-time nature of event service allows managing and preserving component and
task priorities. Details of this infrastructure can be seen in [3].
In the MIC approach domain-specific modeling languages are defined using a
metamodel, which is a UML class diagram, describing the main abstractions/concepts (as
stereotyped classes), relationships, and composition principles, along with the wellformedness constraints of the language. The rest of this document elaborates upon the
metamodel of ESML.
The ESML allows capturing the following aspects of an event-driven component based
system:
1. Interfaces
2. Data Types
3. Events
4. Components
5. Interactions
6. Configurations
Representation of each of these aspects is defined in separate UML class diagram.
Interfaces
The interface aspect allows specification of various interface types implemented
by the components in the system. The Interface class shown in Figure 1 below represents
an interface. The Interface class is allowed to contain Method objects. In the MIC/GME
framework model objects are compound entities that are allowed to contain other objects,
therefore, the interface class is stereotyped as a model. The Method class on the other
hand is an atomic object that is not decomposed any further, and is therefore stereotyped
as an atom. The Method class has a boolean attribute labeled ReadOnly, which denotes if
the method can modify the internal state of a component. The Method class also has an
attribute labeled WCET, which denotes the worst-case execution time of the method. A
folder is a model organization concept in GME. The containment relation between
Interface model and Interfaces folder denotes that all the Interface models created by the
user are stored in the Interfaces folder.
Figure 1: Interface class-diagram
Figure 2 shows screen-shot of an interface model developed under ESML. The blue
icons on the figure represent the methods of the interface.
Figure 2: Interface model
Data Types
The data type aspect allows specification of data types employed by the
components for communication. The DataType class, stereotyped as a model, shown in
Figure 3 below models a data type. It can contain one or more DataElems, that
represents the basic and compound data types of a type system. This specialization of
DataElems into basic or compound data types in expressed with the inheritance
relationship shown in Figure 3. Int, Long, Float, String, stereotyped as atoms, represents
the basic data types, and Record, stereotyped as model, represents compound data type,
that is composed from basic or compound data types. All the modeled Data Types are
stored in the DataTypes folder.
Figure 3: Data Type class-diagram
Figure 4 shows an Image DataType model developed with ESML. The labeled icons
show the members of the defined data type: Integer rows, Integer cols, Float color_depth,
String region_class, and Record pixel_array.
Figure 4: Data Type model
Event Types
The event aspect allows specification of event types. The EventType class,
stereotyped as a model, captures an event. References to DataType objects may be
contained within EventType objects to specify the data type being propagated through the
event. All the modeled Event Types are stored in an EventTypes folder.
Figure 5: Event Type class-diagram
Figure 6 shows an EventType model labeled DATA_AVAILABLE. This event refers to
the ImageType DataType.
Figure 6: Event Type model
Components
The components aspect allows specification of component types. These
component types are instantiated to create a specific application configuration. The
ComponentType class, stereotyped as a model, represents a basic component type.
ComponentType is an abstract class that is concretized into DeviceComponent,
ClosedEDComponent, DisplayComponent, PassiveComponent, CollectionComponent,
LazyActiveComponent, and ModalComponent. This classification of the components
follows from the classification in [2]. All kinds of ComponentTypes may contain
references to Interface types as Facets or Receptacles. Facet specifies the interfaces
exposed by a component, and Receptacles specifies the interface that a component
expects. In addition to Facets and Receptacles, components contain EventPort objects.
EventPorts represent the composition interface of a component, through which a
component may be composed in a system. This composition happens with respect to how
events are produced and consumed by the components. The EventPort class is further
specialized into PublishPort and SubscribePort. PublishPort represent the supplier
interface of a component, and the SubscribePort represent the consumer interface of a
component. The EventTyping association class associates EventTypes with PublishPorts
and SubscribePorts, specifying the specific event types published or subscribed by a
component through the port. When a component subscribes to multiple EventTypes
through multiple subscribe ports, the EventCorrelation attribute of the Component
specifies the triggering condition for the component as a correlation of all the subscribed
event types. All the modeled ComponentType objects are contained in the
ComponentTypes folder.
Figure 7: Components class-diagram
Figure 8 shows a DisplayComponent model, labeled navDisplay:DisplayComponent.
The modeled component has a subscribe port labeled Data_Available, and an invoke port
labeled Update. The subscribe port has been typed with an event type, denoted by the
typing connection between the subscribe port, and the event type reference. The invoke
port (Update) has been connected with the Update method on the Display interface.
Figure 8: Component Type model
Interactions
In the interaction aspect the modeled component types are instantiated, and their
event/data interactions with other components are specified. The InteractionModel class,
captures an interaction diagram. An InteractionModel may contain references to a
ComponentType. This containment specifies instantiation of component types within an
interaction diagram. When instantiating components in the InteractionModel few QoS
attributes may be specified. These attributes are: Period, Deadline, Priority, and
Criticality. InteractionModel may also contain references to references of
ComponentType (i.e. the component instances). This containment is used when the
interactions are captured in multiple InteractionModels, and a component instance from
one InteractionModel is needed within another InteractionModel for specifying additional
interactions.
An InteractionModel also contains references to EventType objects as EventCh
objects. This containment is an instantiation of EventTypes as event channels. An event
channel is a logical mechanism through which components communicate using events.
In addition to EventCh objects, an InteractionModel may also contain references to
EventCh objects. This containment is used when an EventCh instance from one
InteractionModel is required within another InteractionModel.
Three different kinds of component interactions may be specified in an interaction
diagram: Publish, Subscribe, and Invoke. A publish interaction is a connection from the
publish port of a component to an event channel. This interaction specifies publication of
events by an event supplier. One well-formedness rule of this language specifies typing
constraints over this interaction, i.e. the event type associated with the publish port
through the EventType connection, and the event type instantiated as event channel must
be the same. A subscribe interaction is a connection from an event channel to the
subscribe port of a component. This interaction specifies an event consumer relationship.
A similar well-formedness rule specifies typing constraint over this interaction. Finally,
the invoke interaction is a connection from the Receptacle of a component to Facet of
another component. An invoke interaction specifies method invocation relations.
InteractionModel also contains Thread objects. Thread objects represent program
threads of execution. The Thread class has been stereotyped as a set that can contain
component instances. This set containment denotes the mapping of components to
threads of execution.
InteractionModels are contained in Interactions folder.
Figure 9: Interactions class-diagram
Figure 10 shows an interaction model developed under ESML. Notice the instantiation
of various components (gray boxes), and event channels (khaki boxes with red arrows).
The green lines denote a publish connection from the publish port of a component
instance, to an event channel instance. The blue lines denote a subscribe connection from
an event channel instance to the subscribe port of a component instance. The dashed red
lines denote an invocation connection.
Figure 10: Interaction model
Configurations
The configuration aspect specifies the complete system configuration. It specifies
the processors, the mapping of components to processors, and the fault management
modes. The Configuration class, stereotyped as model, captures system configurations.
It may contain Processor objects, and FaultMgmt objects. The Processor class represents
hardware processors, and may contain Layer objects. The Layer class represents a
software architecture layer, and contains references to component instances. Component
instances may be referenced as normal components (NormalComponent), or backup
component (BackupComponent). Normal components are active in the active normal
mode, and must be deactivated explicitly in a fault management mode. Backup
components on the other hand are inactive normally, and must be activated explicitly in a
fault management mode. This containment of component instances in Layer represents
the mapping of component instances from interaction diagrams to processor/layers.
The FaultMgmt class represents a fault management mode. A fault management
mode is specified by processor failures, activation of backup components, and
deactivation of normal components. A FaultMgmt model contains references to
Processors as FailedProcessor. This denotes the failure of a particular processor in a
failure mode. Additionally, a FaultMgmt model contains EnabledComponents set, and
DisabledComponents set. EnabledComponents set contains references to
BackupComponents that are activated in this failure mode. DisabledComponents set
contain references NormalComponents that must be deactivated in this failure mode.
Figure 11: Configurations class-diagram
Figure 12 shows a configuration diagram containing two processors and a fault
management mode.
Figure 12: Configuration model
Figure 13 shows a layer of a processor in a configuration model. The layer contains
references to component instances from the interaction diagram. This denotes a mapping
of component instances to specific processors in the execution platform..
Figure 13: Configuration model (Processor::Layer)
Figure 14 shows a fault management mode. Specifically, the components contained in
the EnableComponents set are being highlighted. These components are enabled when
the system enters this mode on account of a processor failure. The grayed out
components are contained in the DisableComponents set. These components are disabled
in this fault management mode.
Figure 14: Configuration model (fault management mode)
References
[1] Ledeczi A. et al.: GME 2000 Users Manual (v1.1),
http://www.isis.vanderbilt.edu/publications/archive/Ledeczi_A_4_12_2001_GME_2000_U.pdf,
April 12, 2001.
[2] Boeing OEP
[3] Bold-stroke