5.1.1 Challenges for MBE in Embedded Systems

Embedded systems are often developed by integrating components that have been designed and implemented by different teams, often specialized in different disciplines such as mechanical, electronics, and software engineering. As the system behavior emerges from the interplay of multiple distributed components, a key challenge is the correct integration of all these components. System integration is often performed in vertical design chains such as in automotive and avionics, and the development chain typically involves several tools that are not integrated, as explained below.

For example, embedded systems in automobiles are developed as a joint engineering process between an original equipment manufacturer (OEM) and suppliers. The car manufacturer or OEM traditionally specifies the requirements of the various electronic control units (ECUs) for the car. Each ECU is produced by (external) companies known as suppliers. The OEM then integrates the supplier’s components into the vehicle. Achieving independent component development by suppliers necessitates precise and expressive requirements and interface specifications, as well as an integration framework that addresses quality requirements that crosscut multiple components. In practice, requirements are seldom expressed precisely enough, and system integration has to consider the effects of interactions among distributed components. Therefore, projects often use joint iterative development between the OEM and suppliers to ensure corrective feedback cycles.

Furthermore, the specification and implementation of diagnostic functions, for example, is often implemented ad hoc based on a stream of documents exchanged between the OEM and the suppliers. In the automotive domain, model-based approaches leveraging tools such as MATLAB^® [5] and Simulink^® [6] from MathWorks and ASCET^® [7] from ETAS are used to model control functions and generate implementations for different platforms. However, in practice, there is no formal model of diagnosis that is exchanged between parties. Consequently, it is impossible to validate the design and anticipate problems in putting together the various components in the later phases of the development. The lack of an integrated diagnostic model also limits the reuse of diagnostics across models and generations of cars. Redeveloping diagnostic functions, obviously, leads to higher cost in all areas of requirements engineering, design, development, maintenance, verification, and validation.

Models and MBE hold promise for overcoming these exemplar challenges. Models should serve as a common interface between requirements and architecture specification—using models is the only systematic way to ensure that parties can communicate across all development phases from requirements to acceptance tests. The ultimate goal of MBE is that engineers will spend most of their time modeling the system under consideration and then generate code for a specific target platform. This goal is already supported by various tools (including MATLAB and Simulink), but the models often do not include all aspects of the system, as explained earlier. When automatic code generation is not feasible at the level of the entire system, there is still significant benefit if modeling is used for requirements gathering and architecture verification before deploying the actual system. Various terms are used in the literature to denote the use of models in the development process (e.g., Model-Driven Architecture^® [8], model-based design [9], model-driven engineering [10], and model-integrated computing [11,12]). We use the general term MBE as a super-set for all model-based approaches.

In the past decade, significant advances in the area of model specification, transformation, analysis, and synthesis have brought the vision of MBE within reach. Challenges for a comprehensive methodology include providing modeling techniques that result in a consistent, integrated specification; models expressive enough to support both generic and domain-specific aspects of the system; model reusability and integration; model execution; and seamless tool suites.

5.1.2 MBE Process

In general, Fowler [13] identified three ways of using models (specifically, models in UML): sketch, blueprint, and programming language. In sketching, models are used to communicate some aspects of the system. As blueprints, the models should be sufficiently complete as to allow straightforward implementation. By using a modeling language as a programming language, the system is specified at the level of models, and then tools are used to automatically generate the code for the target platform.

In the case of embedded systems, sketches are useful for requirements elicitation because each requirement addresses only a partial view of the system and, thus, a model for an individual requirement is by definition an incomplete specification. Moreover, in the early phases of system engineering, rarely all requirements, let alone their interplay, are understood. On the one hand, sketches as an early analysis tool are generally not hampered by lack of precision in the modeling language proper. To use a model as a blueprint or a programming language, on the other hand, requires the precise specification of the platform and the environment in which the system will operate. Blueprints for embedded systems can support system verification before deploying the actual system, and such verification should include timing requirements, resource usage, and other characteristics of embedded systems. Using a model as a programming language requires powerful tools for code synthesis. Sometimes, code generated from models (e.g., MATLAB and Simulink) is manually adjusted to meet the timing constraints, in which case the link between the code and the model is lost. Moreover, topics such as system reconfiguration and diagnosis are difficult to address. Therefore, a comprehensive MBE approach should involve round-trip engineering.

Figure 5.1 shows a simplified view of the activities and models involved in an MBE process. We use the terms logical architecture and technical architecture as described in Pretschner et al. [14]. The logical architecture is the decomposition of the system into functional components independent of the platform that will execute them, whereas the technical architecture specifies the representation of the logical components in terms of platform-specific entities. A logical architecture can be mapped to multiple technical architectures, each capturing all aspects of a particular deployment. Various other terms are used in the literature to distinguish between logical and technical system aspects. For example, OMG’s Model-Driven Architecture^® (MDA^®) [8] distinguishes between a platform-independent model (PIM) and a platform-specific model (PSM). Furthermore, the Department of Defense Architecture Framework [15] distinguishes between operational views and systems views to separate the logical and technical architectures. We maintain the use of logical and technical architecture to encompass both these standards.

The modeling process involves creating and refining abstractions in a series of steps. Starting with requirements, we first construct requirements models. Next, we construct logical architecture models, which show how the system achieves the functionality described in the requirements models. At the same time, we use the requirements analysis to select and model a deployment and execution platform. Next, we map the logical models onto the platform, thereby obtaining a technical architecture.

Analysis and simulation can be performed at various levels. Logical models can be analyzed for consistency and correctness, whereas technical models can be analyzed for realizability of the deployed system (e.g., schedulability analysis).

The modeling process involves feedback loops, and multiple iterations are possible in each step, within sequences of steps and within the entire process from the beginning. For example, analyzing the technical architecture can reveal hidden requirements and, therefore, may lead to reiterating the process from the initial phase of requirements modeling. We emphasize the need for an iterative process in alignment with the spiral [16] model of agile development methodologies, where requirements often resolve to partial specifications and refinements at one stage can trigger iterations at some earlier stages. An iterative process also accommodates architectural spiking, which is defined as taking a partial set of requirements/use cases and generating a system architecture and implementation based on them, then adding more and more use cases over subsequent rounds. Architectural spikes help in identifying the most critical parts of the system and implementing them first to verify that they can be addressed as expected and, therefore, to mitigate the risks associated with them.

5.1.3 Outline

In the preceding paragraphs, we presented the modeling process in general and various ways of using models, with the implications in the case of embedded systems. We also discussed the current state of the art and challenges in MBE.

The remainder of the chapter is structured as follows. In Section 5.2, we identify requirements for a comprehensive modeling language for embedded systems. This allows us to better position UML’s capabilities in response to this requirements spectrum. In Section 5.3, we present an overview of UML, its metamodeling architecture, extension mechanism, and behavior semantics. We also show how UML can be used for modeling real-time systems, by means of a simplified example from the Bay Area Rapid Transit (BART) [17] system. In Section 5.4, we provide an overview of UML profiles relevant for real-time systems and we cover more detailed aspects from the UML profile for Modeling and Analysis of Real-Time and Embedded systems (MARTE) [18]. In Section 5.5, we discuss how the UML and MARTE together meet the requirements presented in Section 5.2.

5.3.1 Metamodeling Architecture

All graphical notations in UML are backed by a single metamodel. The notation (e.g., a class diagram notation) is the graphical syntax of the language. The metamodel defines the concepts of the language—the abstract syntax. Therefore, the UML metamodel defines the language elements and the relationship between them in the different UML graphical notations (e.g., sequence diagrams and class diagrams). A modeler who uses UML diagrams only as sketches is typically not concerned that much with the metamodel. However, for blueprints and especially for using UML as a programming language [13], the metamodel is very important.

The metalayer hierarchy for any language generally has three layers: (i) the metamodel, or the language specification, (ii) the model, and (iii) objects of the model. The metamodel defines how model elements in a model are instantiated. This layered structure can be applied recursively, such that the same layer that is a model instantiated from a metamodel can be seen as a metamodel of another model at the next lower level of instantiation.

The OMG has developed a modeling language (similar to a class diagram) called the Meta Object Facility (MOF^TM) [25], which is used to specify metamodels, such as the UML metamodel. From the perspective of MOF, the UML metamodel is seen as a user model that is based on the MOF metamodel. Therefore, MOF is commonly referred to as a meta-metamodel.

Figure 5.2 shows the four-layer metamodeling architecture used by the OMG: meta-metamodel (layer M3), metamodel (layer M2), model (layer M1), and the run-time system (layer M0). The top layer (M3) provides the meta-metamodel (MOF) that is used to build metamodels. The UML metamodel (layer M2) is an instance of the MOF. Layer M1 models are user models written in UML, and these models are instances of the UML metamodel. The M0 layer contains the runtime instances of the model instances defined in layer M1. The layers are numbered from M0 upward, but the architecture is not restricted to four layers. In general, more layers can be used by applying the recursive pattern as explained before.

Figure 5.2 also shows an example, where the meta-metaclass Class is defined as part of MOF. Then, UML defines the metaclasses Class and Attribute as part of the UML metamodel. Every model element in UML is an instance of exactly one model element in MOF. The UML Class is instantiated in a user model in a class called Train, with an attribute called Speed. Layer M0 contains an instance of a Train.

The UML Infrastructure [2] defines a common package Core such that model elements are shared between UML and MOF. UML is defined as a model based on MOF used as metamodel; however, both UML and MOF depend on Core. Therefore, Core can be seen as the architectural kernel, and the Infrastructure defines the foundations for both M2 and M3 layers. The Superstructure [3] extends and customizes the Infrastructure to provide the modeling elements of UML.

5.3.2 Modeling with UML

In this section, we start with presenting the UML diagrams briefly, then we comment how they can be used for modeling requirements and architectures, and in the end we present a modeling example with the basic capabilities.

Figure 5.3 shows the types of diagrams provided by UML for modeling structure and behavior. A UML model consists of elements such as packages, classes, and associations. UML diagrams are graphical representations of a UML model. Examples of using UML diagrams for real-time systems are available in Douglass [26, 27 and 28].

Structure diagrams show the static structure of the system at different abstraction levels and how system elements relate to each other. Class diagrams show system Classifiers such as classes and interfaces, their attributes, and relationships between them. Object diagrams show instances of Classifiers and instances of associations between them. Composite structure diagrams show the internal structure of a Classifier. Component diagrams show logical or physical components and dependencies between them via required and provided interfaces. Package diagrams show packages (i.e., namespaces used to group together elements that are related) and dependencies between them. Deployment diagrams show the assignment of software artifacts to execution nodes. A component may be implemented by one or more artifacts.

Behavior diagrams show the dynamic behavior of the system objects over time. Use case diagrams show a set of actions that some actors perform. Activity diagrams show sequences and conditions for coordinating lower-level behaviors. State machine diagrams model the behavior of a part of the system through finite state transitions. Sequence diagrams show the messages exchanged between entities. Communication diagrams show the interaction between entities, where the sequence of messages is given as a sequence numbering scheme. Interaction overview diagrams are similar to activity diagrams but focus on the overview of the control flow. Timing diagrams show interactions and conditions along a linear time axis.

Some diagram types blur the boundary between structure and behavior. For instance, sequence and object diagrams display aspects of both. Figure 5.3 classifies the diagrams according to their dominant trait.

5.3.3 UML Extension Mechanism

The UML standard supports two types of extension mechanisms: lightweight extension through profiles and first-class extension through MOF. The profile mechanism allows UML metaclasses to be specialized for specific domains or different target platforms. In profiles, it is not possible to modify existing metamodels or to insert new metaclasses. Thus, in profiles it is impossible to remove constraints that apply to the UML metamodel, but it is possible to add new constraints that are specific to the profile. In contrast to profiles, in first-class extensibility, there are no restrictions on what changes can be made to a metamodel as MOF enables adding new metaclasses, removing existing classes, and changing relationships. In other words, the profile’s extension defines a new dialect of UML, whereas the first-class extension defines a new language related to the UML.

Stereotypes, tagged values, and constraints are the main extension mechanisms available in a profile. A profile extends a reference metamodel such that the specialized semantics do not contradict the semantics of the metamodel. As such, the reference model is considered “read only.” Stereotypes allow creating new model elements (not new metamodels), new constructs specific to a particular domain or platform. As such, a stereotype extends an existing metaclass and uses the same graphical notation as a class, with the keyword «stereotype» shown before or above the name of the stereotype. When the stereotype is applied to a model element, the name of the stereotype is given between «». A metaclass is extended by a stereotype by using a special kind of association relationship called an extension, which supports flexible addition/removal of stereotypes to classes. The notation for an extension is an arrow pointing to the extended class with the arrowhead as a solid triangle.

For example, for real-time systems, the MARTE profile defines the stereotype «RtUnit» to denote a real-time processing unit as shown in Figure 5.10. The left-hand part of the figure shows the stereotype definition (the stereotype extends the metaclass BehavioredClassifier) and the right-hand part of the figure shows how the stereotype is applied to the model element Train Controller. A stereotype definition must be consistent with the abstract syntax and semantics of UML but can adapt the concrete syntax of UML to the domain. A stereotype can use an icon instead of a UML diagram element as, for example, when defining a clock element.

The properties of a stereotype are called tag definitions. When a stereotype is applied to a model element, the values of its properties are called tagged values. Thus, tagged values are defined as tag–value pairs, where the tag represents the property and the value represents the value of the property. In previous versions of UML, tagged values allowed defining additional properties for any type of model element. Starting with UML 2, a tagged value can be represented only as an attribute on a stereotype. For example, Figure 5.10 shows the Boolean attribute isDynamic defined for the stereotype «RtUnit». If this attribute is true, the real-time unit dynamically creates the schedulable resource required to execute its services [18]. When applying the stereotype, tagged values can be shown in the class compartment under the stereotype name as shown in Figure 5.10 for Train Controller. However, tagged values may also be shown in a comment attached to the stereotype.

A profile consists of a package that contains one or more related extension mechanisms. Profile diagrams (see Figure 5.3) allow defining custom stereotypes, tagged values, and constraints. Constraints allow extending the semantics of the UML metamodel by adding new rules. Constraints can be specified in OCL (not shown here for reasons of brevity).

Compared to pure stereotyping, the advantage of using the UML profile mechanism is that UML’s meta- and meta-metamodels provide a shared semantic and syntactic foundation across all profiles.

5.3.4 UML Behavioral Semantics

UML semantics is a topic that ignites fierce discussions in the modeling community. A common argument of UML critics is that UML has no behavioral semantics. While this was true for the first version of the language, OMG introduced an action-based semantics into the UML version 2.0 standard. Because UML supports expressing behavior in different specialized languages (i.e., state machines and activity diagrams), the semantics defined in the standard uses generic and fine-grained elements, which are composed to support all these sublanguages. UML is also intended to be used in different domains that have diverse execution requirements. Therefore, the UML standard defines variation points for which the documentation states alternative behaviors or leaves explicitly unspecified the behavior, calling for profiles to choose the most appropriate set of behaviors for the intended application domain.

Shortcomings of UML semantics are an important topic of discussion in the modeling community. Some scientists [32] point out that, even if a semantic model exists in the standard, it is not adequate to many usage scenarios. A first criticism is that the semantics is not defined formally, in terms of pure math of other formal languages. Consequently, it is impossible to prove that UML semantics is consistently defined or to develop verification tools that check behavioral properties of UML models. A second criticism is that the standard documents do not contain a chapter that coherently describes UML semantics. In fact, semantics information is spread across the standard and discussed together with the different UML notations. This makes it difficult for the reader to grasp UML semantics and thus paves the way for inconsistencies in the definition and misinterpretation by users. Additional critics complain about the very simple time model, which uses a centralized unique clock and must be completely replaced in many domains. Finally, the variation points that make UML applicable to any domain are subject to criticism as they force adopters to create semantic variations for each such domain.

In the remainder of this section, we describe some of the key elements of UML semantics and how they connect to structural elements of UML. We do not present the semantics of specific UML behavioral notations (e.g., interaction diagrams) but focus on the key elements that are used in the UML standard to construct the semantics of such notations. In our description, we highlight some variation points that are left open for profiles to specify. In Section 5.4.2.2, we discuss how the MARTE profile uses those variation points to create a behavioral semantics amenable to real-time embedded systems.

The first step for understanding UML behavioral semantics is defining how behavior is specified and which elements participate in an instance of such behavior. UML specifies behavior by defining flows of actions. These flows are always attached to a structural element, a Classifier. UML distinguishes between two types of objects with behavior: active and passive. Active objects, on the one hand, are the source of behavior. When created, they execute their actions independently of any other object. Passive objects, on the other hand, execute their actions in reaction to requests from other objects. Active objects subsume familiar programming concepts such as threads of execution and processes. The UML specification uses this more generic representation so that it can include behavior of entities that are not necessarily programs (e.g., people).

Figure 5.11 depicts the subset of the UML metamodel that defines the Behavior class and its connection to Behaviored Classifiers. Behavior is the superclass that represents all behaviors in the UML. Therefore, all the UML notations that describe behavior inherit this basic definition and enrich it by defining more specific types of behavior and their descriptions. Behaviors are associated to BehavioredClassifier. Because the UML Classifiers define sets of instances, the figure shows that behaviors are contained in instances of model elements. This is expressed by the use of a composition relation (black diamond) in the ownedBehavior association of Figure 5.11. The figure also shows that instances can be associated with a classifier Behavior, which represents the behavior that active objects start executing when created.

The UML standard specifies the behavior performed by Behavior objects in terms of actions and action flows. Actions are elementary operations that, given sets of inputs, produce sets of outputs and optionally modify the value of some structural elements. Multiple actions can be composed into flows to specify more complex operations. Flows specify networks of actions and, as such, identify dependencies between subsequent actions and how outputs feed into subsequent inputs. To support different types of systems requiring diverse semantic choices, UML supports variation points in the action model. One such variation point is the type of dependencies that flows can define. UML has two types of flow dependency: control flow, which starts the dependent action only when the previous one ends, and object flow, which starts dependent actions as soon as all their inputs are available. A second variation point arises by the fact that UML does not mandate when the elements of the action output sets become available. Different decisions on when to make the output values available create very different semantics. For example, UML could support semantics that assume synchronous reactions.

Messages and events are the final building blocks that form the base of the UML behavioral semantics. Messages support communication between different instances of UML elements. For example, different message patterns support synchronous calls, asynchronous calls, and signal broadcast. Messages are received in message pools and presented to the receiving instances when they are ready to receive. What happens to an incoming message when the pool is full and in which order messages in the pool are presented to the receiving instance are semantic variation points. Reception of messages is an example of an event. UML events represent the occurrence of a generic state or condition in the UML model instance. Types of events include call events, expression change events, and time events. Some events act as triggers, in which case a Behavior starts executing when the event occurs. Other events just capture a state. For example, a send signal does not even initiate a new behavior whereas a receive signal may.

A very good summary of the UML 2.0 semantics is provided by Selic [33]. We also suggest the interested reader to consult the standard documents [2,3], in particular, to understand how the UML behavior notations (Sequence Diagrams, State Machines Diagrams, Activity Diagrams, etc.) use the core elements we discussed to concretely define their semantics.

5.4.1 Overview of UML Profiles

The profile mechanism has been specifically defined for providing a lightweight extension mechanism to the UML standard via stereotypes, tagged values, and constraints as described in Section 5.3.3. For example, other work [34] presents a UML profile for a platform-based approach to embedded software development using stereotypes to represent platform services and resources that can be assembled together. There is an increasing number of profiles defined in various domains, resulting from either OMG standardization efforts or research outcomes. Different profiles may be overlapping and also inconsistent as each profile tailors the UML for a particular domain or platform. Some of the profiles emerged in previous versions of UML and then new profiles were defined to keep up with the latest changes in UML and to fill in the gaps identified in practice. In the following, we discuss some of the most commonly used profiles for real-time systems, with the historical background and the relationships between them.

The profile mechanism has been significantly refined starting with UML 2.0. Initially, UML 1.0/1.1 provided stereotypes and tagged values, but did not define the concept of a profile. Subsequent revisions of UML introduced the concept of a profile to provide structure to the extension elements. Moreover, to complete the previous versions of UML, the UML 2.0 Infrastructure and Superstructure specifications have defined the profile mechanism as a specific metamodeling technique. In addition, profile diagrams have been introduced in UML 2.0.

UML/Realtime (UML-RT) [35,36] extended UML 1.1–1.4 to support Real-Time Object-Oriented Modeling [37] concepts. It was also the UML dialect of the CASE tool Rational Rose^®/RT. The extension used the standard UML mechanisms of stereotypes, tagged values, and constraints. Thus, UML-RT is a profile, although it was not called a profile initially because there was no profile concept in UML 1.1. For modeling architectural concepts, UML-RT introduced capsules (to model components), ports (to model the interaction of a capsule with its environment), connectors (communication channels between ports), and protocols (to model the behavior that can occur over a connector). A protocol comprises a set of participants (protocol roles), each specified by a set of signals received/sent by it. The corresponding communication sequence can be specified by a state machine and sequence diagrams. While UML-RT was a substantial improvement over the first generation of UML to model real-time systems, it still did not support all notations needed in modeling real-time systems. For example, Krüger et al. [38] presents an extension to UML-RT to support broadcasting. Because UML-RT was not based on an extensible framework such as the one supported by UML 2.0, extending it was an ad hoc process. UML-RT concepts were finally included in UML 2.0, which grants not only the ability to use its constructs in standard UML, but also the ability to systematically extend such constructs. For example, Krüger et al. [39] presents an approach to introducing broadcasting using UML 2.0 facilities similar to the UML-RT approach we mentioned earlier [38].

The UML profiles standardized by OMG include the UML Profile for Schedulability, Performance, and Time (SPT) [40], the UML profile for MARTE [18], and the UML profile for QoS and Fault Tolerance (QoS & FT) [41]. UML-RT focused on component-oriented development of communicating systems but left other aspects of embedded systems unaddressed. The SPT profile [40] was developed to define a resource model, time, and concurrency aspects in UML. MARTE is a new UML profile that updates the previous profile SPT for UML 2.x. MARTE is presented in more detail in Section 5.4.2. The QoS & FT profile [41] defines resource properties such as memory capacity and power consumption. The QoS & FT profile allows users to customize service characteristics (i.e., define new characteristics through specialization) and use tools to perform analyses such as performance and dependability. The QoS & FT profile allows defining a wide variety of QoS properties as compared to the SPT profile, which focused on schedulability and performance. In comparison, MARTE reuses concepts defined in both the SPT and the QoS & FT profile. Moreover, MARTE has the advantage that it allows modelers to attach directly to the design model additional information necessary for various analyses, rather than creating dedicated models for analysis.

OMG also provides the standard for the Systems Modeling Language™ (OMG SysML^TM) [42]. SysML reuses a subset of UML 2 (called UML4SysML) and provides additional extensions to address the concerns for systems engineering applications (called the SysML Profile). Therefore, SysML uses both UML extension mechanisms: the first-class extension via MOF is used to define the UML4SysML subset and then the profile extension mechanism is used not on UML but on UML4SysML. SysML does not use all of the UML diagram types and, thus, it is smaller and easier to learn than UML. In particular, SysML strictly reuses the UML use case, sequence, state machine, and package diagrams. SysML also modifies some of the UML diagrams. The SysML block definition diagram, internal block definition diagram, and activity diagrams extend the UML class diagram, composite structure diagram, and activity diagram, respectively. The SysML “block” is a significant extension in the direction of modeling complex systems. Blocks can be used to decompose the system into individual parts, with dedicated ports for accessing their internals. A block can represent almost any other type of structural entity. Furthermore, SysML allows the description of more general interactions than in software, for example, physical flows such as liquids, energy, or electricity. SysML activity diagrams add support for modeling continuous flows of material, energy, or information. By specifying a continuous rate, the increment of time between tokens approaches zero to simulate continuous flow. Nevertheless, SysML does not extend the time model of UML.

SysML adds two new diagram types: the requirements diagram and the parametric diagram. The requirements diagram captures text-based requirements and the relationships between them—requirements hierarchies and requirements derivation. A requirement can be related to a model element that satisfies or verifies the requirements. Thus, SysML requirements modeling not only supports the process of documenting requirements, but also provides traceability to requirements throughout the design flow. It furthermore provides tabular representations for requirements. Parametric diagrams allow the graphical specification of analytical relationships and constraints on system properties (such as performance and reliability) associated with blocks. Thus, parametric diagrams serve the integration of design models with analysis models.

SysML and MARTE are complementary and could be used together in a common modeling framework [43]. In general, there exist several profiles defined in various domains, and it is not clear how to combine multiple profiles when this is necessary for a particular interdisciplinary application. Therefore, Espinoza et al. [43] presents how SysML and MARTE can be combined and highlights the open issues in terms of convergence between the two profiles. For requirements engineering, SysML provides traceability relations, whereas MARTE provides ways to specify nonfunctional requirements. For system structure, modelers could start with a model specified with SysML blocks and then apply MARTE stereotypes to add additional semantics to these blocks. For system behavior, MARTE adopted the notion of port and flow from SysML, but they have different semantics. Therefore, when combining SysML and MARTE, it is required to define a common consistent semantics. Furthermore, significant differences exist in the specification of quantitative values for analysis (see Espinoza et al. [43] for a detailed analysis of the two profiles).

Even from this short exploration of UML extensions and profiles, it becomes clear that model consistency is a critical aspect of MBE—within and across profiles.

5.4.2 Modeling and Analysis of Real-Time and Embedded Systems

The UML profile for SPT [40] provides a framework for specifying time properties, schedulability analysis (rate monotonic analysis), and performance analysis (queuing theory). MARTE [18] updates SPT for UML 2.x. It allows for modeling of both software and hardware platforms along with their nonfunctional properties. It supports component-based architectures and different computational paradigms, and it allows more extensive performance and schedulability analysis.

In this section, we present an overview of MARTE’s capabilities and we revisit the BART case study introduced in Section 5.3.2.3.