Early timing analysis based on scenario requirements and platform models

Distributed, software-intensive systems (e.g., in the automotive sector) must fulfill communication requirements under hard real-time constraints. The requirements have to be documented and validated carefully using a systematic requirements engineering (RE) approach, for example, by applying scenario-based requirements notations. The resources of the execution platforms and their properties (e.g., CPU frequency or bus throughput) induce effects on the timing behavior, which may lead to violations of the real-time requirements. Nowadays, the platform properties and their induced timing effects are verified against the real-time requirements by means of timing analysis techniques mostly implemented in commercial-off-the-shelf tools. However, such timing analyses are conducted in late development phases since they rely on artifacts produced during these phases (e.g., the platform-specific code). In order to enable early timing analyses already during RE, we extend a scenario-based requirements notation with allocation means to platform models and define operational semantics for the purpose of simulation-based, platform-aware timing analyses. We illustrate and evaluate the approach with an automotive software-intensive system.

the growing number of functionalities has led to thousands of software operations distributed across hundreds of electronic control units (ECUs) that communicate via multiple bus systems [104]. Cyber-physical systems additionally communicate among themselves via wireless ad hoc networks (e.g., automotive vehicle-to-X communication) to provide more advanced functionalities. More generally, these systems increasingly rely on message-based communications. Additionally, the correctness of such systems does not only rely on the functional correctness but also on the time at which actions are performed: They are real-time systems. Since a timing error can lead to human life threat, these systems have to fulfill hard real-time requirements.
For example, the so-called Emergency Braking & Evasion Assistance System (EBEAS) [64,Chapter 4] is an automotive vehicle-to-vehicle driver assistance system, which coordinates with other vehicles (and other in-vehicle ECUs) to autonomously perform actions like emergency braking or evasion of obstacles. Performing emergency braking or evasion only milliseconds too late can harm the life of the passengers and other lives in the environment. Usually, such functionality is subject to end-to-end real-time requirements (e.g., the EBEAS has to perform emergency braking within 50 time units after it detected an obstacle).
Violations of such real-time requirements can occur for various reasons: The ECUs executing the software have restricted resources (e.g., processing power, memory) that increase execution times; the buses and wireless communication media have restricted resources (e.g., throughput, latency) increasing transmission times; the preemption induced by scheduling policies increase response times, etc. More generally, the various properties of the particular resources of the execution platform (resource properties) impact the timing behavior by inducing timing effects (i.e., delays) during the provision of the actual functionality.
Hence, safety standards for the development of softwareintensive systems like the automotive-specific ISO 26262 [67] require the estimation of execution times and needed communication resources. Additionally, to make sure that real-time requirements are fulfilled, timing analyses particularly for the highly safety-critical parts of the system under development shall be performed.
Most of the state-of-the-art approaches for timing analyses taking into account the execution platform apply simulative techniques typically implemented in commercial-off-theshelf tools (e.g., [102,113]). However, such approaches are applied late in the development process, mostly because they rely on the existence of the execution platform or the compiled platform-specific code [29,90,91] (e.g., to compute or measure a worst-case execution time [107]). The detection and fixing of such problems in later engineering phases causes costly development iterations [13,103]. Consequently, there is a need to apply platform-aware timing analyses earlier in the development process, ideally in the requirements engineering (RE) phase. Particularly, the timing-relevant platform resource properties are typically known or well estimated in such early engineering phases due to the knowledge from prior development projects [60,91].
For enabling timing analyses already in the early RE phase, related work provides means to specify and analyze timed behavioral models (typically relying on scenarioor automata-based notations), thereby abstracting from the final platform-specific artifacts. However, approaches analyzing timed scenario-based models require to pre-calculate the timing effects induced by the resource properties and to specify them as part of the time-constrained scenarios [45,55,56,119] or as part of design models that are verified against the scenarios [77,78,81,82]. Approaches analyzing automata-based models likewise require specifying the pre-calculated timing effects as part of the automata [2,11,70,71,79,98], require detailed task models like the state-of-the-art approaches mentioned above [4,5], or provide neither simulation nor visualization means to reveal the causes of real-time requirement violations [40]. Summarizing, most of the related work on analyzing timed models requires reenacting, pre-calculating, and explicitly specifying the timing effects induced by the resource properties (e.g., CPU processing power, bus throughput) in a low-level manner as part of the behavioral models. Thus, timing analysts cannot pragmatically (re-)use platform models with specified resource properties stemming from other sources in the development process (e.g., for documentation and design review purposes) and verify them against the realtime requirements, thereby hindering a broad acceptance of such approaches.
In order to relieve the timing analysts from the burden to pre-calculate and to specify the timing effects induced by the platform resource properties as part of behavioral models, we propose an approach to enable early and platform-aware timing analyses already during the RE phase. Since the targeted real-time software-intensive systems strongly rely on message-based communication, we base the real-time requirements on our timed and component-based dialect [17,64,65] of the scenario-based notation of Modal Sequence Diagrams (MSDs) [48]. Like the related work, the modeling and analysis means provided by our dialect enable specifying and validating real-time requirements but incorporate platform-specific aspects only insufficiently. Thus, to provide both an abstract specification of the execution platform with its particular resource properties and the allocation of MSD specifications to the execution platform, we furthermore extend platform modeling concepts of the real-time modeling UML profile Marte [93]. Based on the modeling languages mentioned above, we mainly introduce a new operational semantics for platform-aware MSDs dedicated to timing analyses. This semantics encompasses an extended MSD message event handling semantics as inspired by Tindell et al. [115] and particularly encapsulates the computation of the resource properties into platform-induced timing effects. This enables verifying the timing effects w.r.t. the real-time requirements specified by timed MSDs in timing analyses through applying simulation and model checking in our tool suite TimeSquare [28]. To operationalize the semantics, we apply our Gemoc approach [22,80] for the specification of executable modeling languages. We illustrate and evaluate the approach with the automotive software-intensive system EBEAS.
In terms of related work, our previous works, and article contributions, we reformulate as follows: • In contrast to related work, our approach enables that the timing effects do not have to be pre-calculated and explicitly specified as part of the behavioral models, so that scenario-and component-based models with realtime requirements and platform models with resource properties can be independently conceived and (re-)used.
• In terms of our previous works, we employ our timed [17,64] and component-based [65] dialect of MSDs [48] for the specification of time-constrained scenario requirements and software architectures. Furthermore, we apply different languages and the tooling of our Gemoc approach [22,80] for the specification of our platform-aware MSD semantics. Based on our semantics and taking the platform models and the allocated time-constrained scenario requirements and software architectures as input, Gemoc generates timed models based on our Clock Constraint Specification Language [24]. These models are executable in our timing analysis tool suite TimeSquare [28]. • As the main contribution, we introduce our new operational semantics for platform-aware MSDs through the application of Gemoc, which computes and thereby separates the timing effects from their inducing platform resource properties, and which extends the abstract MSD message event handling semantics as inspired by Tindell et al. [115]. Furthermore, we introduce a new modeling language for enabling the specification of execution platforms with their resource properties and the allocation of MSD specifications to them through extending the platform modeling concepts of the real-time modeling UML profile MARTE [93].
In Sect. 2, we introduce the foundations that our approach relies on. Section 3 outlines an overview of the approach. Subsequently, we present it in more detail by first presenting our modeling language for execution platforms and the allocation from requirement scenarios to them (cf. Sect. 4). In Sect. 5, we provide conceptual extensions and definitions for message event semantics and timing effects to be considered by timing analyses. Based on these ingredients, Sect. 6 presents our operational semantics for timing analyses. Section 7 illustrates the results through an exemplary timing analysis and model checking. We describe the evaluation in Sect. 8 and related work in Sect. 9. Finally, we conclude and sketch future work in Sect. 10.

Foundations
In the following, we present the foundations for the comprehension of the particular ingredients that our approach relies on. Section 2.1 introduces general foundations on the kind of timing analysis we focus on. In Sect. 2.2, we present the basics of MSDs. Section 2.3 outlines the Marte profile, and Sect. 2.4 introduces the basics of a language for the specification of executable time models. Finally, Sect. 2.5 outlines the Gemoc approach.

Timing analysis for hard real-time systems
We focus on hard real-time systems, for which the violation of a hard real-time requirement may cause catastrophic consequences (e.g., people are harmed) [18]. Hard real-time systems must be designed to tolerate worst-case conditions [72]. Typically, a schedulability analysis (e.g., [18]) for hard real-time systems investigates whether jobs with each an activation time, a processing time, and a deadline w.r.t. the activation time can be scheduled on resources so that always all deadlines are met. As motivated in the introduction, such schedulability analyses are demanded by standards for the development of safety-critical systems.
Response time analysis [8,112] is a well-established a priori analysis technique to check the timing properties of hard real-time systems, which is implemented in many commercial-off-the-shelf tools (e.g., [102,113]). It computes upper bounds on the response times of all jobs and checks whether all response times fulfill the corresponding timing requirements. In simplified terms, the response time of a job is defined as its activation time plus its processing time plus the sum of potential preemption times by other jobs. A job can be a task to be executed on a processing unit or a message to be transmitted via a communication medium. In the case of tasks, the job processing time is the execution time that a processing unit needs to execute the task. The worstcase execution times of the tasks are inputs to task response time analyses [105], and their computation requires the final platform-specific code or a very detailed model of the system [107]. ' In the case of messages, the job processing time is the transmission time that the communication medium needs to transmit the message. Its computation relies on the properties of the physical medium which influence the transmission time (e.g., technology or protocol). Additionally, the activation time also encompasses a queuing jitter that is inherited from the worst-case response time of the sending task [117]. Thus, the results of message response time analyses also depend on the final platform-specific code.
Beyond the timing properties of individual tasks and messages, determining the overall timing properties of distributed real-time systems requires a more holistic view of the system [75]. These timing properties are usually based on event chains starting with an initial system stimulus; involving multiple software components that may be deployed on different ECUs; until the production of an externally observable response event. The timing behavior of event chains converges from the occurrence of task start and completion events, as well as of different events involved in the message transmission. The most used event chain timing property is the end-to-end response time, which is defined as the amount of time elapsed between the arrival of an event at the first task and the production of the response by the last task in the chain [90]. This is of specific importance in our approach, because high-level real-time requirements are usually formulated w.r.t. such end-to-end response times of the event chains. That is, such requirements impose timing constraints between an initial system stimulus and an externally observable response of event chains.
To verify such high-level real-time requirements, existing approaches for end-to-end response time analysis like [29,36,[88][89][90]116] still rely ultimately on the response times of the individual jobs and consequently require the final platformspecific implementation. Thus, they can be applied only in late development phases, like the techniques and tools for the analysis of the individual response times.
Here, we rely on the fact that coarse-grained information about the timing-relevant resource properties is mostly known in the early RE phase from prior projects or expert knowledge [60,91]. Also, we propose to express the real-time requirements based on Modal Sequence Diagrams introduced in the next section.

Modal Sequence Diagrams (MSDs)
Scenario-based notations enable the intuitive specification and comprehension of message-based interaction requirements, and UML Interactions [96, Clause 17] provide such a notation as a visual modeling language by means of sequence diagrams.
To make UML Interactions more suitable regarding universal/existential properties, the Modal profile [48] syntactically extends UML Interactions with modeling constructs as known from Live Sequence Charts (LSCs) [23]. Therefore, this profile introduces a UML-compliant form of LSCs, called Modal Sequence Diagrams (MSDs). In previous works, based on the Play-out algorithm [50], we extended MSDs with modeling constructs and operational semantics for component-based software architectures [65] and for high-level real-time requirements [17,64]. The resulting Real-time Play-out approach [17] defined the operational semantics of such timed MSD requirements and thereby enables their simulative validation.
In this paper, we focus on providing modeling constructs and an operational semantics for the early consideration of execution platform impacts on the timing requirements. However, in order to ease the reading of the proposition, we introduce MSD constructs and semantics (and later our approach) based on the EBEAS example (see Fig. 1). The proposed excerpts of the EBEAS example in Fig. 1 highlight a real-time requirement on the automatic emergency braking maneuver in the case of an obstacle detection. The next sections describe more in detail the structure of component-based MSD specifications (Sect. 2.2.1) as well as their basic and timed semantics (Sect. 2.2.2).

Structure of MSD specifications
A component-based MSD specification is structured by means of MSD use cases. Each MSD use case encapsulates for a specific functionality several interrelated scenarios, which specify requirements on the message-based interaction behavior to be provided by the system under development.
An MSD use case encompasses the participants involved in providing the functionality, as well as a set of MSDs describing the requirements on the interactions between these participants. Such an MSD specification is subdivided into three parts: Types, collaborations, and interaction behaviors, explained in the following.
UML interfaces and components provide reusable types for all MSD use cases of the specification. The interfaces encompass operations that are used as message signatures in the MSDs. For example, the class diagram for the UML package ObstacleDetection::Interfaces in the top of Fig. 1 contains an interface Decisions, which contains an operation enableBraking. This interface is used as required and provided interface in each one port of the components Situa-tionAnalysis and VehicleControl, respectively (see package ObstacleDetection::Types in Fig. 1). For any MSD use case, the actual component-based software architecture is defined by roles of the components. More precisely, we specify component roles and their interconnections by using an UML collaboration (dashed ellipse symbol) [96,Clause 11.7] (ObstacleDetection in Fig. 1). We distinguish between system component roles that are controlled by the system under development (component symbols) and environment component roles that are controlled by the environment (cloud symbols).
For example, the system components sa: SituationAnalysis and vc: VehicleControl communicate with each other via the connector sa2vc. The interface Decisions typing the ports of the corresponding component types determine which messages can be exchanged through this connector. Additionally, both system component roles in turn interact with the environment component role esc: ElectronicStabilityControl via dedicated connectors.
The MSDs define the behavior of the collaboration (cf. abstract syntax links ownedBehavior). We distinguish MSDs into requirement MSDs (no stereotype applied) and assumption MSDs (an MSD with the stereotype «EnvironmentAssumption» applied). The former ones specify requirements on the interaction behavior of the system under development, whereas the latter ones specify assumptions on the behavior of the environment. For example, the MSD EmcyBraking in the bottom of Fig. 1 is a requirement MSD specifying the emergency braking behavior of the EBEAS in the case the adaptive cruise control detects an obstacle, whereas an assumption MSD is only indicated.
An MSD itself encompasses MSD messages, which are associated with a sending and a receiving lifeline, an operation signature, and a connector.
For example, the lifeline vc: VehicleControl (receiving the enableBraking message) represents the equally named role in the collaboration. Consequently, the enableBraking message is associated with the operation signature from the Decisions interface and is specified to be sent via the connector sa2vc in the software architecture.
Based on the kind of the sender role, MSD messages are further distinguished into environment messages and system messages. The former ones are messages sent by the environment to the system (e.g., obstacle and standstill), whereas the latter ones are messages sent by the system internally (e.g., enableBraking) or to the environment (e.g., emcyBraking).
After this short introduction about the structure of component-based MSD specifications, we explain the basic and timed MSD semantics in the following.

MSD semantics
An MSD progresses as message events corresponding to the specified MSD messages occur in the system at runtime (i.e., during Play-out or an actual system execution). Each MSD message is of two different kinds, where both kinds determine for the corresponding message events their safety and liveness properties, respectively. In this article, we focus on MSD messages that allow no occurrences of message events that the scenario specifies to occur earlier or later (safety) and whose corresponding message events must occur eventually (liveness). Message events that do not correspond to any MSD messages are ignored, that is, they do not influence the progress of the MSDs and the MSDs do not impose requirements on them.
As message events occur that can be correlated by the Play-out algorithm with MSD messages, the MSDs progress. This progress is captured by the cut, which marks for every lifeline the locations of the MSD messages that were correlated with the message events.
For example, Fig. 1 shows for the depicted MSD in the bottom its particular cuts c0-c4.
Timed MSDs allow defining real-time requirements by referring to clock variables, which are adopted from Timed Automata [2] and represent real-value variables that increase synchronously and linearly with time. We distinguish clock resets and time conditions. Clock resets are visualized as rectangles with an hour-glass icon, containing an expression of the form c = 0 over a clock variable c. Time conditions are visualized as hexagons with an hour-glass icon and define assertions w.r.t. clock variables. To this end, each time condition defines an expression of the form c value, with a clock c, an operator ∈ {<, ≤, >, ≥}, and an Integer value value. We distinguish minimal delays ( ∈ {>, ≥}) and maximal delays ( ∈ {<, ≤, }).
For example, the MSD in Fig. 1 contains a clock reset and a maximal delay defining that the message events corresponding to all enclosed MSD messages must occur within 50 time units after the message event occurrence corresponding to the MSD message obstacle prior to the clock reset. Such a combination of a clock reset and a time condition forms a real-time requirement. More complex real-time requirements can be formed by specifying multiple MSDs with constraints on overlapping message events (see also our MSD requirement pattern catalog [38] for details).
We opt for applying these existing timed MSD modeling constructs and semantics, instead of ignoring them and adding real-time requirements to the scenarios by means of the Marte profile (cf. next section). By doing so, we do not introduce a further variant of the MSD language and thereby can use the timed MSDs both in Real-time Play-out and in the approach presented in this article.

Platform modeling and allocation with MARTE
The UML profile Modeling and Analysis of Real-Time Embedded Systems (Marte) [93,111] provides modeling means for design and analysis aspects for the embedded software part of software-intensive systems. Marte consists of several subprofiles; and we have sought to reuse as much as possible existing suitable concepts from these subprofiles. In the following, we introduce the subprofiles we use and/or extend: Non-functional properties; generic resource modeling; generic quantitative analysis; and allocations.

Clock Constraint Specification Language (CCSL)
Associated with the Marte profile, we proposed in previous work [24,28] the Clock Constraint Specification Language (CCSL) dedicated to timing specifications. This language is formally defined and tooled to enable the analysis of resulting specifications. CCSL is a formal declarative language for the modeling and manipulation of time in real-time embedded systems [7], initially and informally introduced in Marte [93, Chapter 9/Annex C.3]. The formalism bases on the notion of logical time [37,76], which was originally designed for distributed and concurrent systems, but which was also used in synchronous languages. CCSL generalizes different descriptions of time, based on the notion of clocks, a clock being an ordered set of instants (or ticks) named I. The notion provides a sound way to mix synchronous and asynchronous constraints between clocks. Such a mix enables the symbolic specification of partial order sets on the instants of clocks, which are well suited for the description of a large set of model control flow (e.g., [41,42,73,85,101]). Solving a CCSL model (i.e., doing a run) results in a schedule. A schedule σ over a set of clocks C is a possibly infinite sequence of steps, where a step is a set of ticking clocks σ : N → 2 C . For each step, one or several clock(s) can tick depending on the constraints.
The operational semantics of CCSL models [6] specifies how to construct the acceptable schedules step by step and is given as a mapping to a Boolean expression on C , where C is a set of Boolean variables in bijection with C. For any c ∈ C , if c is valued to true, then the corresponding clock ticks; if valued to false, then it does not tick. Note that if no constraints are defined, each Boolean variable can be either true or false and, consequently, there are 2 n possible futures for all steps, where n is the number of clocks.
Each time a constraint is added to the specification, it adds Boolean constraints on C . The Boolean constraints depend on the definition of the constraint and its internal state. When several constraints are defined, their Boolean expressions are put in conjunction so that each added constraint reduces the set of acceptable schedules. (It is a trace refinement according to [3].) CCSL models are inputs to our tool suite TimeSquare [28], which supports their simulation with the generation of timing diagrams, the animation of UML models, etc. It also supports the exhaustive simulation (when the state space is bounded), enabling the model checking of CCSL models. TimeSquare has been applied for the timing anal-ysis (cf. Sect. 2.1) of software-intensive systems (e.g., [20,41,42,84,85,101]

Pre-defined CCSL constraints
CCSL defines the two constraint kinds clock expressions and clock relations. André [6] formalizes a set of pre-defined CCSL constraints, which TimeSquare provides as a model library so that these constraints can be conveniently used during the specification and the TimeSquare-based simulation of CCSL models. In the following, we explain the pre-defined clock expressions and relations that we apply in this article.
Clock relations impose (synchronous or asynchronous) orderings between the instants of participating clocks.
⊂ : SubClock (subClock: Clock, superClock: Clock ) This relation constrains all ticks of subClock to coincide with a tick of superClock but not vice versa. That is, subClock can only tick when superClock ticks, but it does not have to.
where the coincidence relation ≡ is an equivalence relation (reflexive, symmetric and transitive). It reflects the fact that two instants have the exactly same logical time. = : Coincides (clock1: Clock, clock2: Clock ) This relation constrains all instants of clock1 and clock2 to coincide. That is, the events represented by clock1 and clock2 must occur simultaneously.
≺ : Precedes (leftClock: Clock, rightClock: Clock ) This relation constrains the k th instant of leftClock to precede the k th instant of rightClock ∀k ∈ N. That is, Fig. 2 Exemplary TimeSquare simulation run of the CCSL clock relation Precedes the event represented by leftClock always occurs before rightClock.
where the precedence relation ≺ is a strict order relation (irreflexive, asymmetric, and transitive) between two instants. Figure 2 depicts an exemplary TimeSquare simulation run of this clock relation. In this example, the relation enforces that clock1 always ticks before clock2 ticks.
: NonStrictPrecedes (leftClock: Clock, rightClock: Clock) This non-strict version of the Precedes relation constrains the k th instant of leftClock to coincide with or precede the k th instant of rightClock ∀k ∈ N. That is, the events can also occur simultaneously.
where the non-strict precedence relation is defined by ≺ ∨ ≡.
Clock expressions define a new clock based on other clocks and possibly extra parameters. In the following, we describe the expressions used in this article. +: Union ( clocks: Set(Clock) ) The clock specified by this expression ticks whenever one of the clocks in its parameter set clocks ticks. Consequently, the instant set of the resulting clock (named c here) is such that: where ≡ means coincides with.
meaning that it exists X instants of b between instants of a and the delayed instant of c, and instants of c coincide with some instants of b. ever y...on: PeriodicOffsetP (baseClock: Clock, period: Integer) The clock specified by this expression ticks any period th tick of the baseClock. Note that we apply in this article an always ticking clock globalTime as argument for baseClock so that the clock defined by this expression simply ticks any period th tick.
where id x(i bc ) is the index of the i bc instant in I bc . ∨: Sup ( clocks: Set(Clock) ) The clock specified by this expression ticks with a clock in the parameter set that does not precede the other clocks; that is, it specifies the supremum of the particular instant sets.
meaning that there is no clock d being slower than a or b or being faster than c.
We provide the whole formal semantics definition in [24]. These clock constraints are integrated in our tool suite TimeSquare. Additionally, to ease the application of constraints to specific domains, it is possible to specify userdefined constraints, as introduced in the next subsection.

User-defined constraints
To ease the specification of domain-specific CCSL constraints, we extended CCSL in prior work with the Model of Concurrency and Communication Modeling Language (MoCCML) [25,26]. MoCCML is a specific form of automata that integrates seamlessly with the semantics of CCSL. The automata are a way to specify clock relations, which can be simulated in TimeSquare and stored in user-defined model libraries.
For example, Fig. 4 depicts the MoCCML relation MyUser-definedRelation, which has three clock parameters and a local Integer variable counter initialized with zero. Figure 5 depicts a corresponding exemplary TimeSquare simulation run that initializes three clocks and applies the clock relation myRelation typed by the MoCCML relation on them. The automaton specifies two states A and B with a  transition from one state to the other for each of the states. Such transitions specify possibly coincident parameter clock triggers, guards, and effects. For example, the transition from A to B fires when both the clock parameters cl1 and cl2 (i.e., the clock arguments clock1 and clock2 in the simulation run) tick simultaneously and additionally the guard [counter < 1] holds. When the transition fires, its effect counter++ increments the counter. The transition from state B to A fires on the tick of the clock parameter cl3 (i.e., the clock clock3 in the simulation run) and sets the counter to zero.
The triggers of a transition that leave a state specify which clocks are allowed to tick in this state. For example, the clock parameter cl3 is not allowed to tick in state A, and the clock parameters cl1 and cl2 are not allowed to tick in state B. Furthermore, when in state A, the clocks cl1 and cl2 are forced to tick simultaneously to fire the transition. We provide all the details on the formal semantics in [25].

Model checking CCSL models
TimeSquare is a direct implementation of the formal operational semantics as specified in our previous work [25]. As such, the state of each constraint during the simulation is clearly defined, so that it is also for a CCSL model. Consequently, it is possible based on a CCSL model to exhaustively explore its acceptable simulations. Each time a new state is reached, it is compared to already visited states. If it does not exist, it is added to the visited states, otherwise, a new transition to an existing visited state is created, and it creates a loop representing an acceptable periodic behavior of the CCSL model. In case the set of possible simulations is computed completely, it means that the whole state space is also computed completely and can be serialized. In TimeSquare, such state spaces are typically serialized in the dot language [30] as well as in the Aldebaran format [1]. The resulting files (and consequently the CCSL model) can be verified against properties written in the Model Checking Language [86].

Specifying operational semantics with GEMOC
According to Harel and Rumpe [51], a modeling language consists of an abstract syntax specifying the language concepts and their relations, a semantic domain describing the language meaning, and a semantic mapping relating the language concepts to the semantic domain elements. Our Gemoc approach [22,80] enables to flexibly specify operational semantics for a modeling language following these definitions.
Specifically, the semantic domain is specified by means of a Model of Concurrency and Communication (MoCC). This MoCC is defined by semantic constraints in the form of pre-defined CCSL constraints (cf. Sect. 2.4.1) as well as userdefined MoCCML constraints (cf. Sect. 2.4.2). The MoCC defines the concurrency, the synchronizations, and the possibly timed way the elements of a program interact during an execution. The semantic mapping is specified by the declaration of Domain-Specific Events (DSEs), which associate the abstract syntax and the MoCC. The DSEs are specified by means of our declarative Event Constraint Language (ECL) [27]. ECL is an extension of the Object Constraint Language [94], augmented with the notions of DSEs as well as behavioral invariants, which use CCSL and MoCCML constraints.
The approach is implemented in our modeling language workbench Gemoc Studio [16] for building and composing executable modeling languages. Gemoc Studio takes a language metamodel, an ECL mapping specification, and semantic constraints specified through a MoCC as inputs and automatically derives a modeling workbench with simulation and debugging facilities. Specifically, it automatically derives a dedicated QVTo model transformation [95]. This derived model transformation takes an instance of the language metamodel as input and generates a CCSL model that parameterizes an execution engine based on TimeSquare. The model transformation maps the associated DSEs to CCSL clocks based on the ECL mapping specification and applies the semantic constraints from the behavioral invariants on these clocks.

Approach overview
As outlined in the introduction, our approach encompasses three main ingredients: 1. We propose a Marte-based (cf. Sect. 2.3) UML profile to augment the timed and component-based version of the scenario notation Modal Sequence Diagrams (MSDs) (cf. Sect. 2.2) with platform aspects. This encompasses specification means for a) an execution platform model together with timing-relevant resource properties, b) the allocation of MSD specifications onto these platform models, and c) analysis contexts to be considered during the timing analyses. We call the resulting models platform-specific MSD specifications and describe them in Sect. 4. 2. We conceptually extend the message event semantics for scenario notations in general and MSDs in particular by introducing additional event kinds that occur during the execution of the software on its target platforms. This enables time to elapse between such events during our end-to-end response time analyses, and consequently to introduce platform-specific delays (cf. Sect. 2.1). We also provide means to compute these different delays based on the resource properties defined in platform-specific MSD specifications, which we describe in Sect. 5. 3. The main contribution is the specification of platformaware MSD operational semantics dedicated to timing analyses. We apply the Gemoc approach (cf. Sect. 2.5) to declaratively specify these operational semantics, which formalizes and spawns the platform-induced timing behavior of MSD specifications. Based on the semantics specification, Gemoc automatically derives CCSL models that are input to the timing simulation and model checking tool TimeSquare (cf. Sect. 2.4). We present the semantics specification in Sect. 6 and an illustrating timing analysis in Sect. 7. Figure 6 gives an overview of our application of the Gemoc approach. The Abstract Syntax of conventional (i.e., component-based and timed) MSD specifications is defined at the language level (metamodel level M2) by several parts of the UML metamodel and the Modal profile (cf. Sect. 2.2). We extended this Abstract Syntax by introducing platform and timing analysis aspects through our Marte-based TAM profile. At the model level (metamodel level M1), we provide a Preprocessing QVTo [95] model transformation that takes a Platform-specific MSD Specification as input and computes derived properties. That is, based on the resource properties, this transformation computes delays, which we conceptually present in Sect. 5. The output is a Platformspecific MSD Specification with Computed Static Delays, which is input to another QVTo model transformation MSD-to-CCSL Transformation. This model transformation is automatically derived by Gemoc Studio from our declared DSEs and their MoCC. It encodes the functional and realtime requirements as well as the pre-computed delays and further timing-relevant resource properties into constrained timing effects as part of a CCSL Model. At runtime level (M0), a timing analyst can simulate such CCSL models in TimeSquare to reveal potential real-time requirement violations.

The TAM profile for platform-specific interactions
Conventional component-based and timed MSD specifications as introduced in Sect. 2.2 define platform-independent requirement specifications with real-time constraints; i.e., the software architecture and the MSD specifications have no correlation to any concrete target execution platform. In this paper, we propose to consider the timing behavior emerging from the allocation of component-based MSD specifications to concrete target execution platforms, which we together call platform-specific MSD specifications.
In order to support the modeling of platform-specific MSD specifications, we present in this section the most important concepts of our Timing Analysis Modeling (TAM) UML profile: Execution platforms including the specification of the resource properties that have to be considered in the timing analysis (and consequently in the proposed platform-specific MSD semantics), allocations of logical software components to the platform elements, and analysis contexts. All these concepts extend existing concepts from the Marte UML profile [93]   . We do not present the full TAM profile here but illustrate its use through a platform-specific MSD specification for the EBEAS example, which will also be used as basis to explain the extension of the MSD semantics amenable to timing analysis (cf. Sect. 6).
In the following, we explain the most important stereotypes by illustrating their application to an EBEAS execution platform model depicted in Fig. 7. Therefore, we add platform-specific information to the platform-independent MSD specification introduced in Fig. 1. In Sect. 4.1, we explain how we specify execution platforms with our TAM profile. Subsequently, we explain the allocation of the software components to the resulting execution platform elements in Sect. 4.2. Finally, we present the specification of application software timing properties in Sect. 4.3 and the definition of analysis contexts in Sect. 4.4.

Specifying execution platforms
We provide three subprofiles for the specification of concrete execution platforms together with the properties that impact the timing behavior of the system. For instance, the bottom of Fig

Specifying the hardware processing
In this section, we illustrate means for the specification of hardware elements and processing units. The TamECU is an extension of the Marte stereotype GRM::Resource, which serves as a container for other elements of the hardware platform (e.g., the memory units, the communication media, the peripherals, the processing units or the operating system). The stereotype TamProcessingUnit, contained by the TamECU, extends the Marte stereotype GRM::ProcessingResource. It describes the properties of the processing unit of an ECU or of a microcontroller. Among further properties, it inherits the tagged value speedFactor, which describes the relative speed w.r.t. to the normalized speed of a reference processing unit [93, Section 10.3.2.10]. Furthermore, it adds the tagged value numCores, which specifies the amount of cores that the processing unit provides and consequently the number of tasks that can be handled concurrently.
For example, the EBEAS execution platform (Platform Model package of Fig. 7) contains two microcontrollers («TamECU») :μC1 and :μC2. Both of them specify each 1 pro-cessing unit («TamProcessingUnit»), respectively :PUμC1 and :PUμC2; and both of them are single-core. However, according to their speed factor value, the :PUμC2 processing unit is two times faster than :PUμC1.

Specifying the real-time operating system
In this section, we illustrate means to specify timing-related properties of real-time operating systems, which run on ECUs or microcontrollers and provide services for the application software. The stereotype TamRTOS describes properties of such real-time operating systems. Among others, it enables the specification of shared resources, operating system services, and communication channels on operating system level for ECU-internal communication. In the following, we focus on the specification of the operating system's scheduler since the scheduling strategy strongly impacts the timing behavior of the system. For this purpose, we provide the stereotype TamScheduler, which extends the Marte stereotype GRM::Scheduler. Besides specifications means of properties like the overhead introduced by the scheduler, it inherits two tagged values: the scheduling policy (schedPolicy, e.g., fixed priority or round-robin), and the preemption capability (isPreemptible).
For example, in the execution platform of the EBEAS, the schedulers of both :PUμC1 and :PUμC2 processing units depicted in Fig. 7 implement the most prominent [92,112] real-time operating system scheduling policy FixedPriority and are specified to be non-preemptible. In this policy, all tasks have fixed priorities so that the scheduler dispatches the highest priority task among the ready tasks again and again after the task that is executing has finished. This scheduling strategy is supported by the widespread real-time operating systems of AUTOSAR [9] and OSEK/VDX [66], for example.

Specifying the communication infrastructure
In this section, we illustrate means for the specification of the infrastructure for the communication between distributed components. We provide the stereotype Tam-ComConnection, which extends the Marte stereotype GRM::CommunicationMedia. It provides additional properties compared to the communication media stereotype, but we focus here on the most important ones that are inherited from Marte. The first important property of a communication medium is its latency, which is specified through the inherited blockT tagged value. The second important property of a communication medium is its throughput, specified through the inherited capacity tagged value.
Furthermore, the network interfaces between a TamECU and a TamComConnection need time to encode messages from the software representation to a representation suit-able for the transport via a communication medium and vice versa. Such properties are captured as part of the TamCom-Interface stereotype for ports of TamECUs, inter alia. The TamComInterface stereotype extends the Marte stereotype GQAM::GaExecHost and inherits two tagged values representing the overhead duration implied by the encoding/decoding of the information to and from a communication media: commTxOvh and commRcvOvh.
For example, in the execution platform of the EBEAS, one bus (CanBus) is used to communicate between the two ECUs. The throughput of the «TamComConnection» CanBus connector is set to 100kbit/s and its latency is set to 1ms. Additionally, the communication interface of :μC1's port («TamComInterface») specifies a message encoding overhead of 1ms (commTxOvh=1ms), and the communication interface of :μC2's port specifies a message decoding overhead of 1ms (commRcvOvh=1ms).

Specifying allocations
The Marte subprofile Alloc provides means to allocate software elements to resources of execution platforms (cf. Section 2.3). We reuse the Alloc::Allocate stereotype to specify allocations of MSD application elements onto TAM execution platform elements. This stereotype defines a link that can be used to allocate software components onto processing units, as well as logical connectors onto communication media.
For instance, in the platform-specific EBEAS example, the software components sa: SituationAnalysis and vc: Ve-hicleControl are, respectively, allocated to the :μC1 and :μC2 microcontrollers. This is illustrated in Fig. 7 by the «allocate» links from the logical software components as part of the collaboration to the «TamECU» microcontrollers as part of the execution platform. Analogously, logical connectors between the software components in the collaboration are allocated to «TamComConnection» links in the Platform Model. For instance, the logical connector sa2vc between sa: SituationAnalysis and vc: VehicleControl is allocated to the CanBus connecting :μC1 and :μC2.

Defining the software timing properties
In this section, we illustrate means to specify information about the estimated resource consumption of the application software. Its most important element is the TamOperation stereotype, which inherits tagged values from the Marte stereotype GRM::ResourceUsage [93, Section 10.3.2.13]. It is used to specify the platform-specific timing-related aspects of the operations used as MSD message signatures. We consider here only the two most important tagged values: execTime and msgSize. The tagged value execTime specifies the best-/worst-case execution time of an operation with respect to a processing unit with a speed factor of 1. The msgSize specifies the size of the message associated with the operation.
For instance, in the EBEAS example, both the «TamOperation»s obstacle and trajectoryBeacon on the righthand side of Fig. 7 have a worst-case execution time of 5ms (i.e., the worst-case execution time is specified through one value). In contrast, the operation enableBraking has, specified by the interval value, a best-case execution time of 6ms and a worst-case execution time of 9ms. Note that since the enableBraking operation is part of the vc: VehicleControl, which is allocated to the :μC2 processing unit; and that :μC2 has a speed factor of 2, then the actual best-/worstcase execution time of enableBraking spans an interval of [3 .. 4.5]ms. Additionally, the enableBraking operation is associated with a message whose size is 500bit, and its actual message transmission time has to be calculated based on this size w.r.t. the throughput of the CanBus. These are concrete examples of timing effects (i.e., concrete delay times in an execution context) that are induced by the specified resource properties.

Specifying analysis contexts
In this section, we illustrate means to specify the timing behavior of the system environment. More precisely, it defines a set of timed scenarios that make explicit the hypothesis under which the timing behavior of the system is realized. Such simulation scenarios are called analysis contexts [111, Chapter 9] (cf. Section 2.3).
The main stereotype of the corresponding TAM subprofile is the TamAnalysisContext, which extends the Marte stereotype GQAM::GaAnalysisContext. This stereotype references the platform under analysis and the concrete workload that defines the timed scenarios. The workload is specified through the TamWorkloadBehavior stereotype, which extends the GQAM::GaWorkloadBehavior stereotype. From the extension, it inherits the tagged values demand and behavior that, respectively, define the analysis (timing) assumptions on the environment on the one hand and the system expected (timing) requirements on the other hand. In our context, the behaviors are the requirement MSDs as presented earlier while the demands are assumption MSDs (cf. Section 2.2) triggering the system behavior, where the timing of the environment message is constrained by an arrival pattern. For this purpose, we provide the TAM stereotype TamAssumptionMSD that refines the Modal stereotype EnvironmentAssumption and references an arrival pattern.
We support periodic and sporadic arrival patterns. A periodic arrival pattern, specified by the stereotype TamPe-riodicPattern, constrains the environment message to occur periodically every period time units. We currently do not Analysis context example support explicit jitter deviations from the periodical occurrences, as this timing information would be very detailed in the early RE phase. However, if a jitter is known and as large that a requirements engineer wants to specify it, sporadic arrival patterns can be applied. These are specified by the stereotype TamSporadicPattern and constrain an environment message to occur with a uniform distribution between a minArrivalRate and/or a maxArrivalRate.
For example, Fig. 8 depicts an analysis context for the EBEAS. The entry point is the «TamAnalysisContext» EbeasAnalysisContext. It references the EbeasPlatform container depicted in the bottom of Fig. 7 as well as the «TamWorkloadBehavior» EbeasWorkload. The EbeasWorkload references the behavior MSDs depicted or indicated in Fig. 1. Furthermore, the workload references demand assumption MSDs. These specify that the trajecto-ryBeacon message occurs periodically every 25ms and that the obstacle message occurs sporadically with a rate ranging from 50ms to 55ms, respectively.

Definition of interaction events and delays required for timing analyses
The existing operational semantics for platform-independent MSD specifications as defined by Real-time Play-out [17] only considers synchronous messages, where the events of sending and receiving a message at runtime coincides and no notion of tasks exists. This abstraction is well suited to analyze idealized systems but is not adequate for platformaware analyses. Such analyses require considering different delays introduced by the actual execution on a platform. In order to define these delays, we introduce in this section additional message event kinds, in between which the delays are defined. We associate each message event kind with an equally named lifeline location for MSD messages. To ease readability, we refer to the event kinds and the associated lifeline locations in an undifferentiated way. According to Tindell et al. [115], four kinds of delays are required for the analysis of distributed real-time systems: the message dispatch delay, the message transmission delay, the message consumption delay and the task execution delay (see Fig. 9). These delays are based on locations allowing a more fine-grain cut progression. In case the execution platform does not introduce some of the delays, then the associated events occur immediately one after the other (i.e., at the next instant). In the other case, these delays usually contain two parts, a so-called static part, which can be computed statically according to the properties of the system; and a so-called dynamic part which dynamically emerges from certain workload situation at runtime due to mutual resource exclusion. The static part of the delays and their computation are defined in the remainder of the section and technically implemented as part of the preprocessing transformation mentioned in Sect. 3, whereas the handling of the dynamic part is presented in Sect. 6.2.2. Figure 9 illustrates the location kinds, the fine-grained cuts, and the delays for the enableBraking and emcyBraking MSD messages.
In the definitions of the delays, instead of considering only the worst case (execution/transmission) delays, we also consider their best cases, which are likewise of high interest since they potentially modify the access orders to mutually exclusive resources [10,19,100]. Thus, we compute both lower and upper bounds for all delays and define them as intervals (cf. the specification of best-/worst-case execution times in Sect. 4.3). For space reasons, we only show hereafter the formulas for each upper bound, where the corresponding lower bounds are computed analogously.
The delay definitions presented in the following encompass derived properties (prefixed with a / as in UML). These derived properties are calculated based on a variety of detailed property values as part of the TAM platform models. Furthermore, we encapsulate behind the derived properties the distinct delay computations regarding message exchange between software components allocated to different ECUs (i.e., distributed communication) or to the same ECU (i.e., ECU-internal communication). We only outline the particular ingredients of the derived properties in the following and present the full computations behind them in detail in [61, Section 4.6.1.2].

Message transmission delays
The use of communication media and communication protocols (e.g., the properties of the connector CanBus in Fig. 7) causes a message transmission delay, which must be taken into account by a timing analysis [115]. In order to consider this delay, we encompass the concept of synchronous and asynchronous messages introduced by Harel's original Play-out semantics [50] for Live Sequence Charts (LSCs) [23]. In other words, we distinguish between message send events and message reception events. In case the platform is not defined, such events coincide and correspond to synchronous messages as in Real-time Play-out [17]. However, once the platform is defined, these events are not synchronously correlated with a whole MSD message. In contrast, a causality is defined between the message send and the message reception location of the corresponding MSD message, respectively. See, for instance, the enable-Braking message in Fig. 9, where the cut c1.2 marks that the message is sent but not yet received, whereas the cut c1.3 marks that the message is received but not yet consumed.
The message transmission delays encompass the overall propagation latency (i.e., net latency plus potential overheads) of the communication channel as well as the time to transmit the message. This transmission time depends on the overall message size (i.e., net message size plus control overheads like check sums) in relation to the overall throughput (i.e., media throughput minus potential overhead deductions) of the communication channel. In case of a distributed communication, this overall throughput encompasses its net throughput minus the percentage transmission overhead of the applied transmission protocol and of the applied middleware communication services. Thus, we compute the upper bound of the message transmission delay for an MSD message m as  (9) where m.connector is a UML::Connector associated with m, m.connector.supplier is a TamComConnection (distributed communication) or a TamOSComChannel (ECUinternal communication) that the connector is allocated to, and m.signature is a TamOperation associated with m.

Message dispatch and consumption delays
The notion of message reception in scenario-based formalisms is ambiguous, because it is not clear whether a message reception is the instant when the message arrives at the receiver communication interface or the instant when the receiver application software consumes the message [59]. The distinction between message reception and message consumption is necessary in order to take the message consumption delays into account [115]. Such delays occur due to the decoding of network messages from a representation suitable for the transport via a network to a logical representation suitable to be processed by the application software. Similarly, there is a message dispatch delay between the instant when a message is created by the sending software component and the instant when it is actually dispatched to the network by its network interface [115]. Such delays occur due to the encoding of a logical representation into a representation suitable for the transport via a communication medium.
To distinguish between message creation and message sending as well as between message reception and message consumption, we introduced two additional message event kinds message creation event and message consumption event. These event kinds capture the instant when a message is created by the sending software component and consumed by the receiving software component, respectively. Figure 9 illustrates these event kinds and locations. We define the message creation location to be positioned on the sending lifeline directly before the message sending location (cf. cut c1.1). Similarly, the message consumption location is positioned on the receiving lifeline directly after the message reception location (cf. cut c1.4).
The message dispatch delays encompass the overhead to gain write access to a communication channel (in case of distributed communication, an arbitration time for gaining access to the overall communication system is added) as well as the time to encode a message from its logical representation to a format suitable for the transfer via the communication channel. This encoding time depends on the overall message size (i.e., net size plus potential overheads)  (10) where m.connector is a UML::Connector associated with m, m.connector.supplier is a TamComConnection (distributed communication) or a TamOSComChannel (ECUinternal communication) that the connector is allocated to, and m.signature is a TamOperation associated with m.
Analogously to message dispatch delays, message consumption delays encompass the time to gain read access to a communication channel as well as the time to decode a message from the communication channel format to its logical representation. The (11) where m.connector is a UML::Connector associated with m, m.connector.supplier is a TamComConnection (distributed communication) or a TamOSComChannel (ECUinternal communication) that the connector is allocated to, and m.signature is a TamOperation associated with m.

Task execution delays
The semantics for platform-independent MSD specifications focuses on the message exchange between software components. However, it neglects internal procedures (i.e., tasks) that are executed by the software components to process consumed messages and to create the messages to be sent. This message processing by tasks leads to task execution delays that affect the timing behavior of the system [115] (cf. the execution times of the particular software operations in Fig. 7).
In order to consider such effects, we do not specify explicit task models but rather define that each message is associated with exactly one task that is executed upon the consumption of the message by the receiving software component.
That is, we introduce the two new event kinds task start event and task completion event, which, respectively, represent the start and the end of a task execution. Figure 9 illustrates the new event and location for the enableBraking MSD message. We define the task start to be positioned on the receiving lifeline directly after the message consumption (cf. cut c1.5). Similarly, the task completion is positioned on the receiving lifeline directly after the task start, representing also the cut for the next MSD message (cf. cut c2). The next location is the message creation location (cf. cut 2.1), and so on.
Task execution delays encompass the normalized overall execution time (i.e., net execution time plus potential overheads) required to process a message in relation to the relative speed factor of the executing processing unit (cf. Sect. 4.1) as well as the overall times for accessing memory and resources (i.e., net access times plus overheads  (12) where m.signature is a TamOperation associated with m, m.connector[receiver ] is the receiving software component, m.connector [receiver ].supplier is a TamECU that the receiving software component is allocated to, and m.con [receiver ].supplier. pr ocU nit is the TamProcessin-gUnit of the ECU.
We define a task to start immediately (i.e., at the next instant) after it has consumed its corresponding message if the scheduler can dispatch it (cf. cuts c1.4 and c1.5 in Fig. 9). If the scheduler cannot dispatch it immediately, a dynamic delay occurs (cf. Sect. 6.2.2). When a software component completed a task, it creates a potential subsequent message at the next instant afterward (cf. c2 and c2.1 in Fig. 9).

Specifying operational semantics for the timing analysis of platform-specific interaction models
In Sect. 4, we introduced the TAM profile to enable the modeling of platform-specific MSD specifications. Furthermore, we introduced additional message event kinds to support platform-specific timing analyses as well as the computations for the static delays in between these events (see Sect. 5). In this section, we overview the proposed platform-specific MSD operational semantics dedicated to timing analyses. This section consequently details the semantics-related parts of Fig. 6 from the approach overview section (Sect. 3). The section elaborates on the EBEAS model to illustrate the most important concepts of the semantics, and the reader can refer to [61,Appendix B] for the illustrations of further concepts as well as the complete operational semantics of the TAM profile. Furthermore, our supplementary material [63] and our companion webpage [62] provide the actual technical artifacts as well as additional information.
For each of the following subsections, we start by describing the semantic mapping between the element of the abstract syntax and the CCSL constraints, realized at the language level (metamodel level M2). At this level, Domain-Specific Events (DSEs) are specified with the Event Constraint Language (ECL) in the context of concepts from the abstract syntax, and constrained by behavioral invariants (cf. Section 2.5). This generates a transformation of TAM models into CCSL specifications. Then, we illustrate the CCSL models generated for some TAM models (metamodel level M1). Finally, at the runtime level (metamodel level M0) we describe the corresponding CCSL simulation runs.Section 6.1 describes our encoding of the extended message event handling semantics for MSDs in terms of CCSL. Section 6.2 describes how we encode timing effects induced by the resource properties, and Sect. 6.3 describes our encoding of real-time requirements on these effects and of timing analysis contexts.

Encoding of message event kinds and their order
In order to enable simulative timing analyses of platformspecific MSD requirements, we encoded the semantics of MSDs in terms of CCSL. This encompasses the general occurrences of message events corresponding to the specified MSD messages (cf. Section 2.2.2) as well as the additional message event kinds introduced in Sect. 5.

Language level
At the language level, we explicitly define DSEs and constraints that define the acceptable orders between the occurrences (at runtime) of the DSE instances (at the model level). The order of the occurrences represents the fine-grained cut progression w.r.t. the MSD message locations (cf. Fig. 9).
The upper part of Fig. 10 depicts an excerpt from the semantics specification of MSD message event occurrences. It depicts part of the Abstract Syntax, of the Mapping Specification, and of the applied Semantic Constraints.
Applying ECL, the Mapping Specification in the middle upper part of Fig. 10 defines the DSEs identified in Sect. 5 in the context of a TamModalMessage, like msgCreateEvt (1) and msgSendEvt (2). Each instance of a TamModalMes- Fig. 10 Excerpt from the semantics specification of the message event kinds order and some illustrating models sage will then be equipped with an instance of each DSE. The Mapping Specification also specifies an invariant even-tOrder in the context of a TamModalMessage. Each instance of the DSEs will then be constrained according to this invariant, which specifies the allowed order of the message event occurrences. This order is specified by the user-defined MoCCML relation EventOrderRelation, whose parameters are DSEs.
Consequently, the DSE definition together with the invariants define the mapping between the concepts from the abstract syntax and the semantic constraints.
Looking at the constraint EventOrderRelation, it is specified by a constraint automaton, which defines the allowed order of the DSE parameters. Here, it specifies that the events shall only occur in the following order msgCre-ateEvt, msgSendEvt, msgReceiveEvt, msgConsumeEvt, taskStartEvt, and taskCompleteEvt; possibly infinitely. Note that there is no notion of time in this constraint, meaning that an arbitrary time can elapse between two occurrences.
From this specification, a transformation is automatically generated, to be used at the model level.
Model level At the model level, a timing analyst creates a platform-specific MSD specification and uses the previously generated transformation to generate a CCSL model, which acts as a symbolic representation of all acceptable schedules of the MSD specification; as defined by the semantics specification. The lower part of Fig. 10 depicts an excerpt from the Platform-specific MSD Specification and the corresponding CCSL Model, generated through the MSDto-CCSL Transformation.
The MSD in the left lower part specifies the enableBraking MSD message and its event kinds (1-6) as part of the EmcyBraking MSD (cf. Section 5).
As indicated in the generated CCSL Model in the right lower part of Fig. 10, the derived transformation translates any MSD message to six clocks.
For instance, the enableBraking MSD message is translated to the six clocks (1-6) of the CCSL model of Fig. 10.
Furthermore, for any MSD message, the transformation generates a clock relation typed by the MoCCML relation associated by the ECL invariant (defined at the language level).
For example, for the enableBraking MSD message, the transformation generates the enableBraking_eventOrder clock relation typed by the MoCCML relation EventOrder-Relation. This relation gets the argument enableBrak-ing_msgCreateEvt for the parameter msgCreateEvt, the argument enableBraking_msgSendEvt for the parameter msgSendEvt, etc. Runtime level The CCSL models generated at the model level are simulated in TimeSquare at the runtime level. Figure 11 depicts a CCSL run resulting from the CCSL model depicted in the right lower part of Fig. 10. This CCSL run represents the occurrence order of the particular message event kinds for the MSD message enableBraking.
The rows depict ticks of the clocks, which themselves represent the particular message event occurrences. They are ordered from the top to the bottom, where the topmost row represents the occurrence of a message creation event and the bottommost row represents the occurrence of a task completion event. The ticks correspond to the transitions in the MoCCML relation EventOrderRelation. We assume that at instant 0 the MoCCML relation is in state 1, so that due to the tick of the clock enableBraking msgCreateEvt at instant 1 the state is changed to 2. After the subsequent tick of the clock representing the message send event occurrence at the instant 2, the relation is in state 3 for the next 3 instants, and so on. The arrows visualize the causal dependencies between the clock ticks.

Encoding of platform-induced timing effects
In this section, we present how we encoded the semantics of the timing effects that are induced by the properties of the execution platform. We support two general classes of timing behavior effects. The first class encompasses the different kinds of static delays between the particular message event kinds as discussed in Sect. 5. The second class encompasses delays that dynamically emerge from mutual exclusion of resources when different software components try to access the same resource (e.g., the processor for the task execution, peripheral hardware, or an operating system service) at the same time.

Static delays between message event kinds
As discussed in Sect. 5, message-based communication and task processing involves multiple events during the actual execution on a target platform, and static delays occur between such events. In this section, we present how we encoded these static delays, based on the example of task execution time. Besides the different static delay kinds presented in Sect. 5, the complete semantics also distinguishes between distributed and ECU-internal communication.
As outlined in Sect. 3, we apply a preprocessing step for the computation of the static delays. The lower part of In the following, we present how we specified the operational semantics based on these pre-computed static delays.
Language level In order to consider timing behaviors, we have to keep track of the global time progress. For this purpose, we introduced the globalTime DSE defined in the context of a Model (see Mapping Specification in the middle upper part of Fig. 12). The occurrence of the globalTime instance represents the discretization of the time. This discretization is usually set to the greatest common divisor of all timing requirements; however, to simplify, here it is set to 1ms in the remainder of this paper.
Consequently, we used the globalTime DSE as a reference for counting time, that is, to determine the occurrence of the different delayed DSE instances that are introduced in the following.
Besides the two taskStartEvt (1) and taskCompleteEvt (2) DSEs defined in the context of a TamModalMessage (cf. Sect. 6.1), the Mapping Specification defines two invariants to encode the task execution delay interval. The minEx-ecutionDelay invariant defines the timing behavior for the lower bound of this interval.
To this end, a new DSE taskStartAfterMinExecDelay (3) is defined through the CCSL expression DelayFor (cf. Equation 6). According to the provided parameter arguments (i.e., globalTime, taskStartEvt, minTaskExecutionDelay), this clock expression delays the DSE taskStartEvt by the minimum task execution delay. Then, we specified that As indicated by the excerpt from the generated CCSL Model in the right lower part of Fig. 12, the automatically derived transformation generates a globalTime clock for any MSD specification. Besides the clocks representing the particular message event kinds (1/2, cf. Sect. 6.1), the transformation also generates, for any MSD message, two clock expressions delaying the task start clock by the minimum and maximum execution time, respectively. For instance, the MSD message enableBraking is translated into two CCSL clock expressions DelayFor, defining the new enable-Braking_taskStartAfterMinExecDelay (3) and enableBrak-ing_taskStartAfterMaxExecDelay (4) clocks, respectively. Finally, the transformation generates two clock relations, which restrict the task completion event clock to tick in between the minimum task execution delay clock and the maximum task execution delay clock. For instance, the transformation generates the CCSL relations enableBrak-ing_minExecutionDelay and enableBraking_ maxExecu-tionDelay typed by the CCSL relation NonStrictPrecedes. Both relations enforce the enableBraking_taskCompleteEvt clock to tick in between the occurrences of the clocks enableBraking_taskStartAfterMinExecDelay and enable-Braking_taskStartAfterMaxExecDelay. Figure 13 depicts a CCSL run resulting from the CCSL model depicted in the right lower part of Fig. 12. This CCSL run represents the task execution time interval of the MSD message enableBraking.

Runtime level
The topmost row depicts the ticks of the globalTime reference clock (which always ticks in this run). The row below depicts the tick of the enableBraking taskStartEvt clock at instant 1. This clock tick is delayed by 3 and 5 ticks of the globalTime clock and results in the enableBraking taskStartAfterMinExecDelay and enableBraking taskStartAfterMaxExecDelay clocks, respectively. The two NonStrictPrecedes clock relations enforce the clock enableBraking taskCompleteEvt to tick at some instant between 4 and 6, and it actually ticks at instant 5 in this run.

Dynamic delays due to mutual resource exclusion
Target execution platforms of software-intensive systems have restricted resources, which may not be simultaneously used by different parts of the application. Middleware and operating system services manage the access of the competing software parts to these restricted resources. Typically, such services provide mechanisms ensuring that the resources are accessed in a mutually exclusive manner.
Thus, our proposed operational semantics supports delays that dynamically emerge from the mutual exclusion of processing unit cores, communication media, peripherals, and operating system resources. In the following, we illustrate this with the scheduling of two tasks (each associated with a message processing) that belong to different software components allocated to a same ECU.
Language level The Mapping Specification in the middle upper part of Fig. 14 defines the taskStartEvt and taskCom-pleteEvt DSEs in the context of a TamModalMessage as defined in Sect. 6.2.1. Additionally, the DSE dispatch defined in the context of a TamScheduler represents the instants when the scheduler selects a task for the execution on a processing unit (i.e., the scheduler dispatches the task).
Furthermore, we define two behavioral invariants. The first one, named claimCoreOnTaskStart, is defined in the context of a TamModalMessage. It expresses the relation between the taskStartEvt and the DSE dispatch of the corresponding scheduler (determined via the simplifying pseudocode function "getRelevantScheduler()") by using the CCSL relation SubClock (cf. Equation 1). The relation allows the subClock argument taskStartEvt to tick only when the superClock argument dispatch ticks. We specified whether the dispatch clock can tick through the invariant occupy-CoreOnTaskStart defined in the context of a TamScheduler, which we explain below. By doing so, we prevent a scheduler from dispatching a task when the corresponding processing unit is busy with the execution of another task.
To this end, we first determine all MSD messages that can be sent to one of the software components allocated to the TamECU containing the TamScheduler. From these messages, we define two DSEs through the CCSL expression Union (cf. Equation 5): The DSEs anyTaskStart (1) and anyTaskComplete (2), which represent the union of all task start and task completion events, respectively. These DSEs determine whether any task is started or any task gets completed.
The actual behavior of the occupyCoreOnTaskStart invariant is specified by using the MoCCML relation Non-PreemptiveTaskExecution. Its arguments are the DSE dispatch for the parameter clock occupy, the clocks representing the union of all relevant taskStartEvt and taskCom-pleteEvt DSEs for the newTask and the taskFinish clock, respectively, and the amount of cores of the corresponding processing unit for the Integer parameter numCores. Furthermore, we define a local Integer variable runningTasks that captures the amount of tasks currently running on the processing unit.
The initial state of the MoCCML relation is Cores Available, which defines that the scheduler is able to dispatch new Fig. 14 Excerpt from the semantics specification of the task scheduling, and some illustrating models tasks because the processing unit is not busy with processing other tasks. When a new task is ready to be dispatched in this state and hence the occupy parameter clock as well as the newTask parameter clock tick simultaneously, the variable runningTasks is incremented if the guard [running-Tasks + 1 < numCores] holds. Analogously, when any task running on the processing unit is finished in this state and hence the parameter clock taskFinish ticks, the variable run-ningTasks is decremented. If the amount of currently running tasks equals the amount of cores in this state, the transition to the state All Cores Busy is fired. In this state, dispatching new tasks is not allowed. When any task running on the processing unit gets completed in this state and hence the parameter clock taskFinish ticks, the variable runningTasks is decremented and the transition to the initial state is fired.
Our semantics supports multiple software components allocated to one processing unit, multiple cores per processing unit, and different task priorities, which we do not further discuss here.

Model level
The MSD specification excerpt in the left lower part of Fig. 14 shows the MSD message obstacle focusing on its Task Start (1) and Task Completion (2) events. The lifeline represents the software component sa: Situa-tionAnalysis, which is allocated to the «TamECU» :µC1. This ECU contains a «TamProcessingUnit» :PUµC1 with one core as well as a «TamRTOS» with a «TamScheduler» :OSEK/VDX-Scheduler.
The right lower part of Fig. 14 depicts an excerpt from the generated CCSL Model. Besides the clocks representing the particular MSD message events (cf. Section 6.1), the derived transformation generates for any «TamScheduler» each a scheduler dispatch clock. For example, the transformation generates the clock variable OSEK/VDX-Scheduler_dispatch for the :OSEK/VDX-Scheduler.
Furthermore, the transformation creates for any MSD message each a SubClock clock relation that restricts the related task start clock to tick only when the scheduler's dispatch clock can tick simultaneously. For instance, the transformation generates for the MSD message obstacle the clock relation obstacle_claimCoreOnTaskStart using the SubClock relation.
For any «TamScheduler», the transformation generates two clocks defined by Union clock expressions that determine the union of ticks of all task start and completion clocks. For example, the scheduler :OSEK/VDX-Scheduler is translated to the clocks OSEK/VDX-Scheduler_anyTaskStart (1) and OSEK/VDX-Scheduler_anyTaskComplete (2). The clock expressions get the obstacle_taskStartEvt and obsta-cle_taskCompleteEvt clocks as a set argument, along with other task start and completion clocks.
Finally, the transformation generates for any «TamScheduler» a clock relation that uses the user-defined MoCCML relation NonPreemptiveTaskExecution. For example, the transformation translates the scheduler :OSEK/VDX-Scheduler into the clock relation OSEK/VDX-Scheduler_occupyCoreOnTaskStart. This relation gets the argument OSEK/VDX-Scheduler_dispatch for the parameter occupy, OSEK/VDX-Scheduler_anyTaskStart for new-Task, OSEK/VDX-Scheduler_anyTaskComplete for taskFinish, and 1 for numCores. Runtime level Figure 15 depicts a CCSL run resulting from the CCSL model in the right lower part of Fig. 14. This CCSL run represents a situation in which two different messages request to be processed concurrently by the «TamECU» :μC1.
More precisely, let us assume that the MSD BeaconAcknowledgement indicated in Fig. 1 specifies that sa: Situa-tionAnalysis is responsible for processing information about the trajectories of other vehicles via a message trajectory-Beacon, additionally to processing the obstacle messages as specified by the MSD EmcyBraking. The three topmost rows in Fig. 15 depict the ticks of the clocks representing the consumption, task start, and task completion of the trajectoryBeacon message. The processing unit of :μC1 is not busy with another task at instant 1 when the trajectory-Beacon message is consumed. Consequently, the MoCCML relation NonPreemptiveTaskExecution that types the CCSL relation OSEK/VDX-Scheduler_occupyCoreOnTaskStart is in the state Cores Available (cf. Fig. 14). Thus, the clock OSEK/VDX-Scheduler dispatch is allowed to tick, meaning that the scheduler of :μC1 is able to dispatch the corresponding task. Hence, the clock trajectoryBeacon taskStartEvent ticks simultaneously with the clock OSEK/VDX-Scheduler dispatch at instant 2. Consequently, the clock OSEK/ VDX-Scheduler anyTaskStart ticks at this instant as defined by the clock expression Union. Analogously, the clock OSEK/VDX-Scheduler anyTaskComplete ticks at instant 5 due to the tick of trajectoryBeacon taskStartComplete .
The obstacle message is consumed at instant 2, resulting in the tick of the clock obstacle msgConsumeEvt at this instant. Due to the fact that :PUμC1 has only one core and due to the dispatching of the trajectoryBeacon processing task at the same instant, the MoCCML relation NonPre-emptiveTaskExecution is in the state All Cores Busy from instant 2 to instant 4. Thus, :PUμC1 is blocked from instant 2 to 4 so that the task processing of the obstacle message can be dispatched not earlier than instant 6, at which the obstacle taskStartEvt clock actually ticks. This causes a dynamic delay of 3 time units between the consumption and the actual processing of the message obstacle.

Encoding of real-time requirements and timing analysis contexts
In this section, we present the crucial aspects of the semantics encoding for both the timing analysis results and the timing analysis setup. In Sect. 6.3.1, we explain how we encode the MSD clock resets and time conditions (i.e., the realtime requirements) in CCSL, which the timing analysis in TimeSquare determines as fulfilled or violated by the timing behavior of the system. In Sect. 6.3.2, we explain how we encode analysis contexts defined by timing analysts to investigate the simulation scenarios that interest them.

Clock resets and time conditions
The combination of a clock reset and a time condition in an MSD represents a real-time requirement (cf. Sect. 2.2.2). A violation of such real-time requirements can lead to hazards in the case of safety-critical systems, and our timing analysis approach aims at revealing such violations in the early RE phase.
In this section, we present how our proposed semantics encodes combinations of clock resets and time conditions. We illustrate the semantics for delays with a strict upper bound, representing a maximum message treatment response time. In the complete semantics specification, we also support minimal delays and non-strict bounds.
Language level The Mapping Specification in the middle upper part of Fig. 16 shows the invariant rtReqStrictUp- Fig. 16 Excerpt from the semantics specification of the clock resets and time conditions, and some illustrating models perBound defined in the context of the Modal stereotype ClockReset. The invariant initially determines the time condition associated with the clock reset. If the operator of the time condition defines a strict upper bound (i.e., the operator equals "<"), the implication becomes true so that the invariant is relevant to the context clock reset.
Remember that we do not extend the MSD modeling language but refine its semantics for the purpose of timing analysis. For example, we conceptually introduce more finegrained event kinds in Sect. 5 and describe their realization in the Gemoc mapping specification in Sect. 6.1. That also implies that we have to define in the following for the semantics of real-time requirements which of the new fine-grained event kinds they constrain, as the clock resets and time conditions can only be specified between messages.
Thus, for strict upper bound maximal delays, we define that the real-time requirement constrains the time elapsed between the message reception (prior to the clock reset) and the task completion (prior to the maximal delay). For this purpose, we first determine the last message reception DSE precedingMessageReceptionEvent (1) directly preceding the clock reset. We illustrate this in a simplifying manner with a pseudocode function, which applies the clock expression Sup (reference not depicted in the figure, cf. Equation 8). Analogously, we determine the last task completion DSE constrainedTaskCompletionEvent (2), that is, the completion DSE of the task that precedes the associated time condition. Then, we define a new clock upperBoundEvent (3) representing the upper bound of the time condition by using the clock expression DelayFor, which delays pre-cedingMessageReceptionEvent by the upper bound value. Finally, we constrain the ticks of constrainedTaskComple-tionEvent to occur before the ticks of upperBoundEvent by using the clock relation Precedes (cf. Equation 3).

Model level
The left lower part of the figure shows an excerpt from the MSD EmcyBraking, which encompasses the MSD message obstacle prior to the clock reset clockReset1 and the MSD message standstill prior to the time condition c < t brake , parameterized by the t brake variable. The focus is on the message reception event for obstacle (1), the task completion event for standstill (2), and the time condition defining an upper bound w.r.t. the clock reset (3).
The derived transformation generates the CCSL Model whose excerpt is represented in the right lower part of Fig. 16. It contains the globalTime clock keeping track of the overall time progress, as well as the clocks for the occurrences of the message reception and task completion events for both the obstacle and standstill MSD messages, respectively (cf. Sect. 6.1).
Furthermore, the transformation generates for any clock reset each three CCSL expressions. The first expression defines a new clock clockReset1_precedingMessage ReceptionEvent (1) that represents the slowest occurrence of the message reception event among the MSD messages The second Sup expression defines a new clock clockRe-set1_constrainedTaskCompletionEvent (2) that represents the occurrence of the task completion event of the last MSD message prior to the time condition, that is, the clock stand-still_taskCompleteEvt. Third, the transformation generates a clock expression DelayFor defining the clock clockRe-set1_upperBoundEvent (3). This expression delays the message reception event clock stemming from the last MSD message prior to the clock reset by the value of the time condition. In the case of the MSD model in Fig. 16, it delays clockReset1_precedingMessageReceptionEvent by t_brake time units w.r.t. globalTime.
Finally, the transformation generates for any clock reset each a CCSL relation Precedes, which enforces the task completion event clock stemming from the last MSD message prior to the time condition to tick before the delayed clock representing the upper bound value of the time condition. In our example, the relation clockReset1_rtReqStrict UpperBound applies the clock clockReset1_constrained TaskCompletionEvent as argument for leftClock and the clock clockReset1_upperBoundEvent as argument for right-Clock. Figure 17 depicts a CCSL run resulting from the CCSL model depicted in the right lower part of Fig. 16. This CCSL run represents a fictional situation, where the time condition value placeholder t brake has two distinct concrete values, leading one time to the fulfillment and another time to the violation of the real-time requirement.

Runtime level
The ticks of the clocks obstacle msgReceiveEvt and standstill taskCompleteEvt (row 2 and 7) represent the occurrences of the message reception and task completion events of the MSD messages obstacle and standstill, respectively.
For both, the clock expression Sup is used to define the new clocks clockReset1 precedingMessageReceptionEvent (row 3) and clockReset1 constrainedTaskCompletionEvent (row 6). Furthermore, the CCSL expression DelayFor delays the clock clockReset1 precedingMessageReceptionEvent by t brake time units, defining the new clock clockReset1 upperBoundEvent . This clock is depicted in both the rows 4 and 5 for the two distinct concrete values of t brake . The relation Precedes enforces the tick of clockReset1 constrainedTaskCompletionEvent to occur before the tick of clockReset1 upperBoundEvent .
In the example situation, clockReset1 constrainedTaskCompletionEvent ticks at the instant 7. This clock tick fulfills the Precedes relation if the value t brake is 8 so that clockReset1 upperBoundEvent ticks at the instant 9 (row 4). This means that the software execution on the specified platform fulfills the real-time requirement for the given analysis context.
However, if the value of t brake is 4 (row 5), the tick of clockReset1 constrainedTaskCompletionEvent does not fulfill the Precedes relation because the real-time requirement is too tight. More precisely, TimeSquare cannot solve the underlying Boolean expression (cf. Sect. 2.4), and the simulation stops with a deadlock in case t brake = 4. This situation represents a real-time requirement violation. Note that instead of classically defining the clockRe-set1_rtReqStrictUpperBound as a relation, it is possible to define it as an assertion in which case TimeSquare stipulates where the assertion is violated instead of producing a deadlock.

Timing analysis contexts
To conduct a particular timing analysis, the engineers have to specify the concrete simulation scenario that they want to investigate. Such an analysis scenario is known as an analysis context [93,111].
The analysis context defines how often and at which instants the environment events triggering the system behavior can occur. Like in Marte, we refer to them as arrival patterns.
We support periodic as well as sporadic arrival patterns in our semantics (cf. Sect. 4.4). Whereas periodic arrival patterns specify the triggering of environment events that occur repeatedly with a fix period and without jitter, sporadic arrival patterns specify the triggering of environment events that occur sporadically with certain restrictions. These restrictions encompass a minimum arrival rate before an event may occur, a maximum arrival rate until an event has to occur, and combinations of both that can also be applied to represent jitters. In this section, we exemplify the semantics of analysis context scenarios with a periodic arrival rate, whereas we define the semantics of sporadic arrival patterns by com- Fig. 18 Excerpt from the specification of the periodic arrival patterns semantics, including example models bining the semantics of periodic ones and of delay intervals (cf. Sect. 6.2.1).

Language level
The Mapping Specification in the middle upper part of Fig. 18 shows the invariant periodicPattern defined in the TamAssumptionMSD context. This invariant enforces MSD message creation events defined as part of a «TamAssumptionMSD» with a periodic arrival pattern to occur periodically.
In the invariant periodicPattern, we first determine whether the associated arrival pattern of the context TamAs-sumptionMSD is a periodic one. If this implication holds, we define a new DSE periodicActivation (1) that ticks every period ticks due to the CCSL expression PeriodicOffsetP (cf. Equation 7). Its arguments are the globalTime DSE and the tagged value period of the TamPeriodicPattern. Subsequently, we determine the initial MSD message of the TamAssumptionMSD. Finally, we enforce the msgCre-ateEvt DSE of this MSD message to tick simultaneously with the periodicActivation DSE by using the CCSL relation Coincides (cf. Equation 2).

Model level
The excerpt from the MSD in the left lower part shows the «TamAssumptionMSD» BeaconFrequency. It specifies the trajectoryBeacon environment message to be sent from the environment role v2x: V2XCommunication to the sa: SituationAnalysis. The «TamPeriodicPattern» associated with the «TamAssumptionMSD» defines that the creation event of this environment message occurs periodically every 3ms (1).
As indicated in the excerpt from the generated CCSL Model in the right lower part of Fig. 18, the derived transformation generates for any «TamAssumptionMSD» with a periodic pattern each a CCSL expression PeriodicOffsetP. This CCSL expression gets the globalTime as argument for the baseClock parameter and the tagged value period of the «TamPeriodicPattern» as argument for the equally named clock parameter. In our example, the transformation generates the PeriodicOffsetP expression with the value 3 applied as argument for period, defining the new clock trajectoryBea-con_periodicActivation (1).
Finally, the transformation generates for any «TamAssumptionMSD» with a periodic pattern each a CCSL relation Coincides. This clock relation gets two clocks as arguments: The clock representing the message creation event of the initial MSD message, and the newly defined clock representing the periodic activation. In our example, the transformation generates the Coincides relation trajectoryBeacon_periodicPattern with the clocks trajec-toryBeacon_msgCreateEvt and trajectoryBeacon_periodic Activation as arguments. This relation forces the clock tra-jectoryBeacon_msgCreateEvt to tick every 3 ticks of the globalTime, meaning that the message creation event of the initial MSD message trajectoryBeacon occurs every 3ms.  Figure 19 depicts a CCSL run resulting from the CCSL model depicted in the right lower part of Fig. 18. This CCSL run represents the periodic occurrence of the message creation event of the initial MSD message trajecto-ryBeacon defined in the MSD BeaconAcknowledgement.

Runtime level
The topmost row depicts the ticks of the globalTime reference clock. The middle row depicts the ticks of the trajectoryBeacon periodicActivation clock, which ticks every 3 rd tick of the globalTime clock. The bottommost row depicts the ticks of the trajectoryBeacon msgCreateEvt clock, where the Coincides relation enforces this clock to tick simultaneously with the trajectoryBeacon periodicActivation clock.

Timing analysis example
In this section, we illustrate how the different aspects of the semantics presented in Sect. 6 work together. For this purpose, we first explain a simulation of a CCSL model generated from the whole platform-specific MSD specification example presented in Sect. 4. Afterward, we illustrate the possibility to perform model checking on the CCSL model.

Simulation of a platform-specific MSD model
As a recapitulation, Fig. 20 depicts the MSD specification parts that are the most relevant for the timing analysis example illustrated in this section. Let us consider the MSD BeaconAcknowlegement, which was in Sect. 2.2 only indicated as part of the MSD specification introduced in Fig. 1. This MSD specifies the exchange of trajectory information between a vehicle and the other vehicles in its environment (through trajectory beacons). More precisely, it specifies the v2x: V2XCommunication to send a trajectoryBeacon message to the sa: SituationAnalysis, which shall acknowledge the reception by sending back an ack message. These interactions have to be executed on the target platform in addition to the MSD EmcyBraking.
In our context, an end-to-end response time analysis has to determine whether such platform-specific MSD specifications fulfill their high-level real-time requirements (cf. Sec- One key question of such timing analyses is whether the resources provided by the platform have a sufficient performance to execute the application software consuming the resources. For example, it can reveal that the processing resource executing the software component sa: Situation-Analysis is not fast enough to process some operations in time; or that the latency of the communication media is too high to deliver some messages in time. Answering such questions is even more important when, at some points in time, the system workload is high. For example, several messages like obstacle and trajectoryBeacon can arrive at sa: Situa-tionAnalysis within a small timeframe so that the receiving software component has to process them concurrently. The very same situation occurs when several messages have to be delivered via a single communication medium at the same time. In the following, we illustrate the detection of a realtime requirement violation by means of a simulation in TimeSquare. The violation occurs due to a situation, in which the workload triggered by the environment is too high so that the target platform is not able to fulfill the real-time requirement. Figure 21 depicts an excerpt of the CCSL simulation run, which results from the platform-specific MSD specification excerpt in Fig. 20.

Row 1 depicts
the tick of the clock trajectoryBeacon msgCreateEvt at instant 50. This tick stems from the environment message trajectoryBeacon defined in the assumption MSD BeaconFrequency, where its arrival pattern specifies this message event to occur periodically every 25ms. As explained in Sect. 6.3.2, our semantics enforces the message creation events to occur exactly at these periodic instants. Thus, trajectoryBeacon msgCreateEvt occurs any 25ms, and the simulation excerpt depicts its second tick in the overall run. Row 2 depicts the trajectoryBeacon taskStartEvt clock tick at instant 54, which emerges due to two aspects. First, we assume that the (not depicted) clocks representing the preceding trajectoryBeacon send, reception, and consumption events occur with small static delays at the instants 51, 52, and 53. Second, the corresponding task can only start when its scheduler can dispatch it. As described in Sect. 6.2.2, trajectoryBeacon taskStartEvt depends on its superclock OSEK/VDX-Scheduler-µC1 dispatch (row 4), which is able to tick at this instant as explained in the description for row 4. Row 3 depicts the subsequent tick of the trajectory Beacon taskCompleteEvt clock at instant 60. This instant results from a task execution delay, which is computed as described in Sects. 5.3 and 6.2.1 as follows. The operation signature of trajectoryBeacon is a «TamOperation» having an execTime with the value 5ms. The corresponding receiving component role sa: SituationAnalysis is allocated to the «TamECU» :μC1, whose «TamProcessingUnit» :PUμC1 has a speedFactor with the value 1. Thus, the task executing the operation needs 5ms 1 = 5ms for the processing. Row 4 depicts the ticks of the OSEK/VDX-Scheduler-µC1 dispatch clock. As described in Sect. 6.2.2, this clock can only tick if the corresponding processing unit for the execution of a requested task dispatching has a free core. This is the case at instant 54, where the trajectoryBeacon is ready to be processed by its corresponding task. Thus, the trajectoryBeacon taskStartEvt clock depicted in row 2 is allowed to tick simultaneously. However, OSEK/VDX-Scheduler-µC1 dispatch cannot tick during the 6 following instants because the task for processing trajectoryBeacon is not completed until then and the processing unit has only one and thereby no further free core.
Row 5 depicts the tick of the obstacle msgCreateEvt clock. This tick stems from the obstacle environment message defined in the ObstacleArrivalRate assumption MSD. The arrival pattern of this message specifies that the corresponding environment event occurs sporadically between any 50 and 55ms. Our semantics enforces the corresponding message creation event to occur at instants inside this interval. In the proposed run, obstacle msgCreateEvt occurs within this instant interval, at instant 51. Row 6 depicts the tick of the clock clockReset1 precedingMessageReceptionEvent at instant 53. This clock stems from the clock reset (assuming that it has the identifier clockReset1) defined in the Emcy-Braking MSD, which is specified directly below the obstacle environment message. As explained in Sect. 6.3.1, the corresponding semantics enforces clockReset1 precedingMessageReceptionEvent to tick on the last message reception event occurrence before the clock reset. Thus, this clock ticks on the tick of obstacle msgReceiveEvt depicted in row 7. Row 7 depicts the tick of obstacle msgReceiveEvt clock at instant 53. Here, we assume that it ticks immediately after the preceding (not depicted) message send clock, which itself ticks immediately after the tick of obstacle msgCreateEvt (row 5). Row 8 depicts the subsequent obstacle msgConsumeEvt clock tick at instant 54 without a substantial delay. Row 9 depicts the tick of the obstacle taskStartEvt clock at instant 61. This tick emerges from the fact that its superclock OSEK/VDX-Scheduler-µC1 dispatch (row 4) cannot tick earlier than this instant, because the trajectoryBeacon processing task is completed only one instant before. Thus, a dynamic delay occurs until the scheduler can dispatch the obstacle task. Row 10 depicts the obstacle taskCompleteEvt clock tick at instant 67 after the obstacle processing task is completed. The task execution delay of 5ms is computed analogously as described above for trajectoryBeacon in row 3.
We skip the detailed explanation of the computation and determination of the further static and dynamic delays and focus in the remainder on the clocks generated from the elements specified at the end of the MSD EmcyBraking.
Row 15 depicts the tick of the clockReset1 upperBoundEvent clock. As explained in Sect. 6.3.1, our semantics uses this clock to represent the maximal delay c < 50 w.r.t. the preceding clock reset in the EmcyBraking MSD. As explained in the description for row 6, this clock reset is represented by the clock clockReset1 precedingMessageReceptionEvent . To represent the maximal delay value 50 and span the corresponding real-time requirement, clockReset1 upperBoundEvent ticks at instant 103, that is, 50 instants after the tick of clockReset1 precedingMessageReceptionEvent at instant 53. Row 16 depicts the standstill taskCompleteEvt clock tick, which represents the final task completion event for the message standstill at instant 105 due to the delays between the event occurrences before. Row 17 depicts the tick of the clock clockReset1 constrainedTaskCompletionEvent . As explained in Sect. 6.3.1, our semantics enforces this clock to tick at the same instant as the last task completion event clock before a clock reset (cf. row 16). Furthermore, this clock tick has to precede the tick of the clockReset1 upperBoundEvent clock at instant 103 (row 15) to fulfill the real-time requirement. However, the clock ticks at instant 105 due to the platform-induced timing effects. Thus, TimeSquare cannot solve the underlying Boolean expression (cf. Sect. 2.4), and the simulation stops with a deadlock (or an assertion is notified, see Sect. 6.3.1) This represents a real-time requirement violation for the analysis context in which the trajectoryBeacon and obstacle messages are almost simultaneously received by the software component sa: SituationAnalysis.
The detection of such a real-time requirement violation typically opens up a variety of potential countermeasures to fix the defect. One possible countermeasure would be to speed up the «TamECU» :μC1 to which the sa: Situation-Analysis software component is allocated to: A speedFactor of 2 would allow to process trajectoryBeacon and obstacle within each 3 instants. This would reduce the end-to-end response time until the task completion of standstill by altogether 4 instants, thereby fulfilling the real-time requirement. Other countermeasures are the addition of a further core to :μC1 enabling the concurrent processing of the two messages, an exchange of the communication medium between the two TamECUs improving the message transmission times, the relaxation of the real-time requirement in communication with all stakeholders, etc.

Model checking of a platform-specific MSD model
As presented in Sect. 2.4.3, TimeSquare allows constructing the state space representing the set of all possible simulations. The fact that there are different simulations possible from a single CCSL model results from different sources of nondeterminism. For example, the clock obstacle msgCreateEvt in the proposed model is subject to a sporadic arrival pattern so that it can tick between any 50 and 55ms. It is important to verify the status of the requirements for any of these values. This is also true for all the interval delays defined in Sect. 5. We ran the state space construction on the model generated from the MSD specification in Fig. 20. It contains 9,775 states and 14,865 transitions. More interestingly, it contains a periodic behavior that fulfills the requirements [62]. This happens when the obstacle msgCreateEvt ticks at time 55, reducing the dynamic delay of the associated task and allowing the standstill task to complete before the deadline.
This shows the known fact that simulation and formal verification complement each other [43]. Typically, there are traces in specification state spaces that fulfill the requirements, whereas other traces violate them. This can be dangerous, because timing analysts who are not aware of the fact that the simulations cover only a subset of the overall state space could be easily satisfied with some conducted simulations yielding only positive results. This can happen despite the debugging environment provided by Gemoc Studio, which allows for a step-by-step investigation of specific executions by discovering the state space dynamically, helping the timing analysts to investigate different simulations [16].
While we prove the possibility to use the generic exhaustive simulation feature to model check a platform-specific MSD specification, it remains very costly. We are currently investigating if it is possible to make it more affordable; even if not totally exhaustive, typically by running parallel simulations as inspired by Monte Carlo techniques.

Evaluation: Example application EBEAS
We evaluate our timing analysis approach by means of an example application [121] and organize its description in this section according to the guidelines by Kitchenham et al. [74] and by Runeson et al. [108]. In our example application, we investigate the efficacy of our approach with the running EBEAS example, serving as a representative for software-intensive distributed real-time systems. To answer the evaluation questions, we apply different variants of the platform-specific MSD specification introduced in Sect. 4.
In the example application, we evaluate a software prototype based on the Eclipse Modeling Framework (EMF) [33]. For the modeling language aspects, we rely on the EMFbased UML modeling tool Papyrus [34]. Beyond editors for conventional UML models, Papyrus enables the specification of UML profiles and provides the Marte profile. Furthermore, the Papyrus-based tool suite ScenarioTools MSD [109] provides the Modal profile and corresponding editor and analysis functionality. We extended both profiles by our TAM profile as sketched on the left upper side of Fig. 6 in Sect. 3. For the semantics specification (right upper side of Fig. 6), we rely on the tool suite Gemoc Studio [32]. It provides the timing analysis tool TimeSquare [114] as well as the languages ECL, CCSL (including libraries for the pre-defined constraints), and MoCCML, with their textual editors relying on the EMF-based language development framework Xtext [120]. Finally, it applies the EMF-based QVTo implementation [35] for the model transformations. We provide the application and an evaluation dataset in our supplementary material [63].

Context
The objective of our example application is to evaluate whether our approach is useful for timing analysts. For this purpose, we examine the following evaluation questions (EQ): EQ1: Does our timing analysis approach generate syntactically and semantically correct CCSL models? EQ2: Does our timing analysis approach reduce the engineering effort for specifying CCSL models?
Based on the aforementioned example application objective and evaluation questions, we define three evaluation hypotheses H1-H3. Their detailed evaluation is described in Sects. 8.3 to 8.5.

Subject Specifications
Besides the first author, we employ two different master-level students, student-1 and student-2 to support the evaluation. Student-1 has approximately four-year experience in modeling and simulating MSD specifications, as well as oneyear experience with Marte platform modeling and timing analysis in TimeSquare during the evaluation conduct. Furthermore, he conceived and implemented a very early version of our timing analysis approach [12]. Student-2 has approximately one-year experience with modeling MSD and Marte specifications, as well as with TimeSquare during the evaluation conduct.

Hypothesis H1
We define evaluation hypothesis H1 as follows: Our MSD semantics for timing analyses correctly encodes the timing effects that are induced by the resource properties provided as modeling means by our TAM profile (cf. evaluation question EQ1).
For evaluating H1, two different students prepare four different platform-specific MSD specifications that jointly cover all resource properties that are provided as modeling means by our TAM profile. Afterward, they generate CCSL models from them and investigate whether any of the platform properties induces each the expected timing effect with the expected delay duration.
We consider H1 fulfilled if the students observe each a timing effect as we expect to be induced by all resource properties specifiable with our TAM profile.

Data collection preparation
As a basis for evaluating H1, the students prepare a set of platform-specific MSD specifications that jointly cover all resource properties that are supported by our semantics. A large part of these resource properties is covered by a platform-specific MSD specification that is presented in [12,Section 7.2] as a proof of concept by student-1, which we call MSD-spec-1. In this proof of concept, typical use cases in the course of a timing analysis are constructed. This encompasses the determination of several real-time requirement violations through the timing analysis and the repeated adaptation of the specification until the real-time requirements are fulfilled.
For any of the remaining resource properties that are not covered by MSD-spec-1, student-2 specifies each a dedicated model (altogether 17 further models) that covers the respective resource property to reproduce the corresponding induced timing effect.

Data collection procedure
For evaluating hypothesis H1 with MSD-spec-1, student-1 conducts the following specification and timing analysis process: 1. He specifies a platform-independent MSD specification as explained in Sect. 2.2.1.

He specifies a platform model based on information about
real-world platforms, as explained in Sect. 4. 3. He specifies an allocation from the MSD specification to the platform model and annotates software component resource consumption properties. 4. He specifies analysis contexts and iteratively conducts the timing analysis in TimeSquare. In the course of the timing analysis, he iteratively encounters platform-induced real-time requirement violations, determines their respective causes, and adapts the resource properties until all real-time requirements are fulfilled. This procedure enables him to reenact every timing effect induced by a resource property that is both considered by our semantics and specified in the proof of concept model. Particularly, he simulatively determines whether for any specified resource property each the expected timing effect occurs.
To evaluate hypothesis H1 for the remaining resource properties that are not covered by MSD-spec-1, student-2 proceeds for any dedicated model specific to a resource property as follows: 1. He specifies the resource property with one value each so that the expected induced timing effect in one case ful-fills a real-time requirement and in the other case violates the same real-time requirement. For this purpose, he reenacts the semantics for the corresponding resource property to conceive a property value such that the induced timing effect leads to each the fulfillment and the violation of a real-time requirement according to his expectations.
In the case of static delays, he reenacts the respective delay computation formula (cf. Sect. 5). One example of dynamic delays is the construction of a runtime situation in which two software components concurrently access one resource. 2. He conducts the timing analysis in TimeSquare. For the static delays, he already determines in the preprocessed model (cf. Sect. 6.2.1) whether the corresponding delay changes according to his expectations. For both dynamic and static delays, he simulatively determines whether the corresponding timing effect as well as the real-time requirement fulfillment or violation for the resource property under investigation occurs as expected.
We documented the test results for all resource properties that induce timing effects, as covered by our MSD semantics for timing analyses. This includes how a particular resource property induces a respective timing effect and how this timing effect sums up to which kind of delay. Furthermore, the documentation includes which platform-specific MSD specification covers the resource property and whether the student observed the delay as expected. We omitted this documentation in this paper for space reasons; their details can be found in [61,63].

Interpreting the results
Our documented test results show that our semantics encodes the timing effects induced by the resource properties as expected. Furthermore, all modeling means as provided by our TAM profile are considered by the semantics. Thus, we consider our hypothesis H1 fulfilled.

Hypothesis H2
We define evaluation hypothesis H2 as follows: Manually specifying a platform-specific MSD specification from scratch and automatically generating a CCSL model from it is more efficient than specifying the corresponding CCSL model manually from scratch (cf. evaluation question EQ2).
For evaluating H2, the first author counts the number of model elements for the four platform-specific MSD specifications as well as the CCSL models. He categorizes each model element w.r.t. atomic model operation kinds and measures the durations for conducting each operation kind.
Furthermore, one student measures the transformation execution times for generating CCSL models from the four platform-specific MSD specifications.
Finally, on the one hand, the averaged measurement values for each operation kind are multiplied by the corresponding number of model elements in the four MSD specifications and summed. The transformation execution times are also for each model added to the aforementioned sum, yielding variable H2.1. On the other hand, the averaged measurement values for each operation kind are multiplied by the corresponding model elements in the generated CCSL models, yielding variable H2.2.
At the end, the results for the MSD specification and the CCSL models are compared. We consider H2 fulfilled if H2.1 < H2.2.

Data collection preparation
Model preparations As a basis for evaluating H2, student-2 copies MSD-spec-1, extends the platform model to five Tam-ComConnections connecting five TamECUs, and allocates the software architecture to it. We present the resulting model in Fig. 7 and call it MSD-spec-2. Furthermore, student-1 specifies another variant of a platform-independent MSD specification for the EBEAS, which encompasses 24 MSDs and hence is more complex in terms of interaction requirements. He allocates it to the simple platform model of MSD-spec-1, which we call MSD-spec-3. Finally, student-2 copies the variant of the platform-independent MSD specification encompassing 24 MSDs, extends the platform model of MSD-spec-2, and adds the allocation specification. We call the resulting model MSD-spec-4, which is the most complex of all considered MSD specifications in terms of interaction requirements as well as the platform model.

Technical measurement preparations
To technically prepare the duration measuring of the different model operation kinds as part of the evaluation of H2, we apply and adapt the Eclipse plugin ModRec [87,106]. ModRec aims at designing and executing empirical studies on modeling in a Papyrus and EMF context. As a prerequisite for this purpose, it provides a Papyrus model listener to record atomic model operations, which we consider in H2.
For measuring atomic model operation kinds in the Papyrus-based ScenarioTools MSD, we slightly adapt Mod-Rec to simply log timestamps for each of the model operations. In addition, we implement a custom listener for the Xtext-based CCSL editor, because Xtext renders the underlying EMF model on every keystroke in a new model copy. Furthermore, we prepare a dedicated measurement model for both the platform-specific MSD specifications and the CCSL models. We provide the measurement tool suite and models in our supplementary material [63].
Empirical measurement preparations Regarding the design of the evaluation of H2, the first author automatically counts the different model elements for MSD-spec-1 to MSD-spec-4 as well as the different model elements of the corresponding generated CCSL models CCSL-model-1 to CCSL-model-4. Afterward, we categorize the model elements w.r.t. to different atomic model operation kinds that are required to specify each of these model elements. This includes, for example, the initial creation of a model element, specifying its name attribute, specifying further values, or referencing other model elements. This procedure yielded the following amounts of different model operation kinds: • 34 conventional UML model operation kinds that are required for the platform-independent part of MSD specifications, spanning several kinds of individual UML editors (e.g., class diagrams for component types and interfaces, composite structure diagrams for architectures, sequence diagram editors for interactions, and form editors to set the detailed properties of all elements). The conventional UML model operation kinds strongly depend on the editor capabilities provided by Papyrus for the particular type of the considered UML partial model. Consequently, we measure each of them individually in the data collection (cf. Sect. 8.4.2). For example, MSDspec-1 contains 5 component types, and for each of them the requirements engineer has to 1) create the component type and 2) specify its name attribute, resulting in 2 atomic model operation kinds for this model element. • 7 generic stereotype model operation kinds, as the editor capabilities for stereotypes in Papyrus are all the same. That is, we generalized the 69 different operation kinds for specifying the platform-specific information via our TAM profile to these 7 generic stereotype operation kinds. These encompass, for example, 1) creating a UML base model element, 2) applying a stereotype, and 3) specifying a numeric tagged value. In the data collection (cf. Sect. 8.4.2), we use the measurement values of these generic stereotype operation kinds in a representative manner for each of the 69 TAM stereotype operations. For example, MSD-spec-1 contains 2 TamProcessingUnits, and each of them requires creating the UML base element (generic stereotype operation kind 1), applying the stereotype (operation kind 2), and specifying the numerical tagged values numCores and speedFactor (each time operation kind 3). • 19 CCSL editor operation kinds, which directly emerge from the different kinds of model elements used in our transformation and thereby CCSL models. These CCSL editor operation kinds encompass the declaration of Integer and clock variables, as well as the specification of the clock expressions and clock relations as introduced in Sect. 2.4 and as used by our operational semantics overview in Sect. 6.

Data collection procedure
For any of the 34 UML model operation kinds, the 7 generic stereotype model operation kinds (representative for the 69 TAM stereotype model operations), and the 19 CCSL editor operation kinds (cf. Sect. 8.4.1), the first author measures each 10 times the duration for conducting the operation as fast as possible in the dedicated measurement models. That is, we measure the raw, time-wise effort for conducting the particular operations in the corresponding editors, which also includes typical duration deviations due to wrong mouse clicks or correcting typing errors. We provide all measurement points as well as minimum/maximum times and standard deviations in our dataset [63]. We then multiply the average values of the measurements for the operation kinds with the number of the corresponding modeling elements in MSD-spec-1 to MSD-spec-4 and CCSL-model-1 to CCSL-model-4. The second column of both the left-and right-hand side of Table 1 shows the aggregated amounts of model elements for the MSD specifications and CCSL models, respectively. For both the MSD specifications and CCSL models, the table also includes a breakdown into the particular model element kinds. First, it details for the MSD specifications the amounts of types, architectural elements, and interaction elements for the platform-independent part (cf. Sect. 2.2.1) as well as the amounts of the different element kinds of the platform-specific part (cf. Sect. 4). Second, it details for CCSL models the amounts of the particular model element kinds like variable declarations, clock expressions, and the different clock relation kinds (cf. Sect. 2.4). Then, the third column of both the left-and right-hand side of Table 1 shows the aggregated sums of the average measurement values multiplied by the number of corresponding model elements, where we again provide the detailed multiplication scheme and values in our dataset [63].
To yield H2.1, we add the averaged transformation execution times for deriving the corresponding CCSL model (fourth column on the left-hand side of Table 1) to the sum of the multiplied mean average measurement values for the effort on specifying the platform-specific MSD specification. For measuring the particular times, student-2 instruments the particular QVTo transformations in such a way that timestamps are generated and performs several times the transformation from any platform-specific MSD specification to each the corresponding CCSL model. The fifth column on the left-hand side of Table 1 lists the summarized times of specifying the platform-specific MSD specifications and of executing the transformation, representing the variable H2.1.
The third column on the right-hand side of Table 1 yields H2.2 directly.

Hypothesis H3
We define evaluation hypothesis H3 as follows: The generated CCSL models are syntactically correct (cf. evaluation question EQ1).
For evaluating H3, all generated CCSL models used for the evaluation of H1 and H2 are opened in the CCSL editor and simulated in TimeSquare.
We consider H3 fulfilled if all CCSL models generated during the evaluation of H1 and H2 can be opened in the CCSL editor and can be simulated in TimeSquare without the occurrence of any error.

Data collection preparation
The model preparations described in Sects. 8.3.2 and 8.4.1 form also the basis for evaluating H3.

Data collection procedure
During the evaluation of H1 and H2, the students open every generated CCSL models in the CCSL model editor and simulate them in TimeSquare. These models encompass CCSL-model-1, CCSL-model-2, CCSL-model-3, CCSLmodel-4, and the 17 further CCSL models dedicated to certain resource properties. The students were able to open and simulate all models without the occurrence of any error.

Interpreting the results
We consider hypothesis H3 fulfilled because 100% of the 21 CCSL models generated during the evaluation of H1 and H2 were opened in the CCSL model editor and simulated in TimeSquare without the occurrence of any error.

Summarizing the results
The fulfilled hypotheses indicate a positive answer to our evaluation questions. That is, our timing analysis approach Table 1 Hypothesis H2: Comparison of measured efforts for manually specifying platform-specific MSD specifications and automatically generating CCSL models (H2.1) vs. specifying CCSL models manually (H2. 2) generates syntactically and semantically correct CCSL models and reduces the engineering effort for specifying them. The effort is even less if we assume that the platformspecific aspects are added to an already existing platformindependent MSD specification as presented in Sect. 2.2.1. Summarizing, the fulfilled hypotheses give rise to the assumption that our timing analysis approach is indeed useful for a timing analyst.

Threats to validity
The threats to validity in our example application according to the taxonomy of Runeson et al. [108] are:

Construct validity
• During the evaluation conduct, both students had little knowledge on timing analysis and on the Marte platform modeling, and they had a lot and little knowledge on modeling MSDs, respectively (cf. Sect. 8.2). Thus, the students' knowledge is not comparable to the knowledge of timing analysis experts, who are versed in applying conventional timing analysis tools for later development phases or TimeSquare. Such experts might tend to apply the commercial-off-the-shelf-tools that they are used to, or might argue that timing analyses are too imprecise in an early development phase with only coarse-grained information.
However, with their limited knowledge, the students managed to specify the particular models, to inject and understand real-time requirement violations, and to reen-act the computation of timing effects based on resource properties through our operational semantics. This indicates that the approach is indeed applicable and efficient, especially for timing analysis novices. • Student-1 conceived the initial timing analysis approach as well as MSD-spec-1 in the context of [12], and the other platform-specific MSD specifications are variants of MSD-spec-1. Thus, he knew the functional principle of the approach and could have been biased toward it.
However, in addition we employed student-2 for conceiving the other platform-specific MSD specifications as well as evaluating the hypotheses, and the first author had comprehensive discussions with both students. • Regarding the evaluation of H1, the resource properties provided as modeling means by our TAM profile might not be extensive enough, might not be useful, or might not be applicable during the early development phase of RE.
However, we argue that the considered resource properties represent typical timing-relevant ones at an adequate abstraction level due to their systematic determination by means of a literature review [12,Chapter 3]. This literature review considered scientific as well as industrialgrade publications and investigated which resource properties influence the timing behavior of software-intensive systems and which concrete effects on the timing behavior they induce. Furthermore, it ensured the applicability during RE by excluding publications describing resource properties that have a too detailed abstraction level for a timing analysis during this early development phase. • Regarding the evaluation of H2, conducting a user study on specifying complete particular models might provide more information on the subjective efforts. In contrast, we measure the raw, time-wise efforts on conducting the particular model operation kinds in dedicated measurement models.
Nevertheless, Durisic et al. [31] report that such simple and atomic metrics based on model operations are a good and objective indicator for predicting the overall effort, though having certain threats to validity as every metric. Particularly, we do not measure and thereby depend on any cognitive effort that is very subjective and difficult to measure: Conceiving the models on paper or whiteboards before modeling in the tool, discussions with peers, design and complexity issues of the respective modeling languages, diagram layouting or text indenting, error search and debugging, model evolution, general cognitive abilities or current cognitive state of the engineer, language expertise, etc.
Internal validity Regarding the evaluation of H2, we multiply the amount of model elements of the four complete MSD specifications and CCSL models with the measured raw, time-wise efforts of corresponding atomic model operation kinds, where the measurements stem from dedicated measurement models. Under consideration of the transformation execution times, we then conclude that the effort on specifying platform-specific MSD specifications and generating CCSL models is less than the effort on manually specifying the corresponding CCSL models. These relations might be incorrect. However, comparing the sheer amounts of model elements for both model kinds, it is obvious that manually specifying a CCSL model cannot outperform an automatic CCSL model generation, even under consideration that platform-specific MSD specifications have to be created beforehand.
External validity We only considered one example application, and the platform-specific MSD specifications are variants of the same system. Furthermore, example applications in general cannot ensure external validity. Thus, we cannot generalize the conclusions to all possible platformindependent MSD specifications, other types of softwareintensive systems, or software-intensive systems in other industry sectors. Nevertheless, the example application is typical for software-intensive systems, so that we do not expect large deviations for other types of systems.

Reliability
• Regarding the evaluation of H1, the students could have judged incorrectly whether the platform-induced timing effects occur as expected. However, we mitigate this threat by employing two different students, whose judgments complement each other and are critically scrutinized by the first author. Furthermore, we provide the evaluation data on H1 and the example application in our supplementary material [63] for the sake of replicability. • Regarding the evaluation of H2, a different person could have a different modeling scheme or a different setup of hardware and operating system, so that this other person's measurements would yield different duration values. However, we believe that we applied the most efficient modeling scheme for each of the operation kinds and that the hardware and operating system setup can be neglected on modern systems in a human interaction context. Furthermore, we provide all the data, the measurement software, and the measurement models in our supplementary material [63], so that interested people can replicate the measurements in other settings.

Related work
The approaches described in this section analyze timed models. Typically, they specify behavioral models and analyze them for safety and liveness properties in a timed setting. The expressiveness of the underlying notations and the particular model contents influence the purposes and capabilities of the analysis techniques, as explained in the following two paragraphs.
Approaches that only specify application behavior or the requirements on it can only verify that the timed behavior fulfills the checked properties and can be implemented at all. However, such approaches are not platform-aware: They are not intended to verify that an execution platform is sufficient to fulfill the real-time requirements (cf. Sect. 2.1). This is due to the fact that the timing effects induced by the resource properties are not in the scope of the analysis techniques or the analyzed models. Thus, such approaches can be compared to our Real-time Play-out approach [17], which simulatively validates timed MSDs to reveal unintended behavior and is the basis for verifying MSDs for safety/liveness properties [44].
If the models additionally specify the timing effects induced by the execution platform, the analysis techniques can also include (end-to-end) response time analyses as outlined in Sect. 2.1 and addressed by the approach presented in this article. However, this causes much effort, because these low-level timing effects (e.g., ECU, bus, and scheduling behavior) have to be pre-calculated based on the platform resource properties and explicitly specified for this purpose (e.g., through delays in the particular timed notations)additionally to the (requirements on the) timed application behavior. Furthermore, such models dedicated only to the purpose of timing analyses are typically difficult to reuse for or base on existing models for other purposes in the design process (e.g., discussing the requirements models with stakeholders or conducting design reviews of the platform models).
In contrast, our approach enables to reuse existing timed scenario-based requirements as well as platform models. The application of de facto standard, UML-based modeling languages that are understandable for many stakeholders, and, particularly, the straightforward specification of resource properties instead of their induced timing effects facilitates to (re-)use models also for/from other design process purposes. Our semantics encapsulates the computation of the timing effects induced by the particular resource properties and enables to simulatively verify them against real-time requirements as part of the timed MSDs.
The related approaches can be distinguished into approaches for analyzing timed scenario-based models (Sect. 9.1) and for analyzing timed automata-based models (Sect. 9.2).

Analysis of timed scenario-based models
Beyond the explanations regarding the analysis of timed models in general above, most approaches described in this section annotate scenario-based requirements formalisms with real-time requirements as well as timing effects induced by the platform resources (cf. [58] for an overview on timed scenario notations). Furthermore, these approaches provide different non-simulative techniques for their respective timing analyses. However, the outputs of these timing analysis techniques are plain yes/no results and partly logged information about the processing times. In contrast, our timing analysis of the generated CCSL time models in TimeSquare enables to comprehensively detect real-time requirement violations straightaway by means of interactive simulation.
Live Sequence Charts (LSCs) [23] extend Message Sequence Charts [68] with modeling constructs and semantics for specifying and analyzing safety and liveness properties. Harel and Maoz [48] transferred these modeling constructs to a UML profile to enable the specification and analysis of LSC models in the widespread UML tools. Extended with time conditions and their semantics [47,49], they form our timed MSD variant with its operational semantics given by Real-time Play-out [17] (cf. Sect. 2.2). Thus and as explained above, approaches based on timed LSCs/MSDs typically specify and analyze the (requirements on the) general application behavior constrained by realtime requirements but do not consider response time analysis based on platform models.
In contrast, Larsen et al. [77,78,82] present an approach to formally verify real-time design behavior specified through Timed Automata (TA) [2] against scenario-based functional and real-time requirements specified by means of timeenriched LSCs. For this purpose, the LSC requirements are translated to observer TA that are composed with the design behavior TA that encompass pre-calculated timing effects induced by the platform. The resulting TA network is verified against reachability properties on the observer TA in a model checking tool. However, the need for detailed intracomponent design models encompassing platform timing effects impedes the application of the approach in the early RE phase.
Similarly, Lettrari and Klose [81] simulatively verify realtime design models against scenario-based functional and real-time requirements that are specified by means of timeconstrained UML 1.3 Sequence Diagrams augmented with concepts from LSCs. For this purpose, they generate instrumented code from the design models so that timestamps are recorded in the simulative code execution. These timestamps are used to check whether the implementation fulfills the realtime requirements specified in the scenarios. However, the need for executable software code generated from detailed design models again impedes the application of the approach in early RE.
Hassine [55,56] annotates the scenario notation of Timed Use Case Maps (TUCM) [57] and its underlying architecture with timing-relevant effects. The annotated TUCM model is transformed into an Abstract State Machine model [14] that is simulated in an external tool, similarly to our approach. However, the simulation tool is not capable of interpreting the annotations. Instead, it is instrumented so that execution traces are generated and persisted in a text file. These execution traces potentially contain log messages about real-time requirement violations and have to be inspected manually to reveal the violated requirement and the violating timing effect. In contrast, we generate CCSL specifications that we directly simulate in TimeSquare, enabling to detect and comprehend potential real-time requirement violations straightaway. Furthermore, the approach only allows to specify delays (i.e., timing effects) induced by the platform, but not the causes of these effects (i.e., the resource properties).
Wang and Tsai [119] apply Message Sequence Charts [68] to specify functional requirements and the Specification and Description Language [69] to specify the underlying architecture. They annotate these models with a task model including real-time requirements and with timingrelevant effects, respectively. They use algorithms to first compute an allocation of tasks to processing resources and subsequently perform a schedulability analysis to verify the effects against real-time requirements, yielding a plain yes/no result. In contrast, we explicitly specify the allocation of software components to processing resources in our platform-specific MSD specifications and simulate the resulting CCSL specifications, where the simulation facilitates to comprehend potential real-time requirement violations. Again, the approach does not distinguish between resource properties and the timing effects that they induce.
Han and Youn [45] apply Interval Timed Colored Petri Nets [15] to specify delays for the execution of event sequences and annotate these models with real-time requirements. They present algorithms for the computation of event sequence processing delays and for the verification of the delays w.r.t. the real-time requirements. Similarly to the approaches mentioned above, the outputs of these algorithms are plain yes/no results as well as the logged processing times. Thus, our simulative approach again enables a better comprehension of real-time requirement violations. Furthermore, the approach only allows to specify static delays in terms of timing effects.

Analysis of timed automata-based models
Automata-based notations are in terms of expressiveness similar to scenario-based notations. However, scenario-based models are quicker to understand than automata-based ones [83,99]. Due to the focus on the inter-instead of the intracomponent behavior, we further argue that a scenario-based notation is the natural choice for the requirements on the message-based interactions of distributed software-intensive systems, which we address in this article. Apart from that, our approach is different from most of the approaches mentioned in this section as explained in the beginning of Sect. 9. That is, it does not require specifying the low-level timed platform behavior with timing effects pre-calculated from the resource properties, but rather enables using the resource properties as part of dedicated platform models in a straightforward manner.
Gerber and Lee [40] present the automata-like process algebra Calculus for Communicating Shared Resources and an accompanying proof system for schedulability analyses. Beyond timing effects and constraints for the behavioral part, it allows the allocation to shared and prioritizable resources like CPUs or communication links. The underlying computational model captures the fact that a resource can only process one action at an instant. Thus, from the approaches described in this section, it comes closest to our approach of allocating behavioral to platform models and encapsulating timing effects in the operational semantics. However, the resources are part of the behavioral model, so that behavioral and platform aspects cannot be conceived independently. From an analysis point of view, the approach is not capable of interactively simulating and visualizing the timed behavior for revealing the causes of real-time requirement violations.
Jahanian et al. [70,71] introduce the graphical specification language Modechart, which is inspired by Harel's Statecharts [46] and allows to annotate real-time requirements (i.e., deadlines) and timing effects (i.e., delays) to automata-based behavioral models. Modechart comes with a tool set [21] for the specification, formal verification, and simulation of the corresponding models. Unlike in our approach, neither dedicated platform models specifying the resource properties nor their translation into the induced timing effects are in the scope of Modechart. Thus, the detailed scheduling behavior of the whole system has to be specified and annotated with all possible timing effects to verify it against the real-time requirements.
Ostroff [98] introduces time-augmented automata called Timed Transition Models and an automatic verification approach for this language. The timing behavior is specified by means of lower and upper time bounds for the transitions, and the real-time requirements are specified through properties in real-time temporal logic [97]. Two different algorithms compute reachability graphs from the timed transitions models and analyze them for different temporal properties. Again, every possible timing effect induced by the execution platform has to be calculated and explicitly specified by means of time bounds for the transitions to consider it in the analysis.
Timed Automata (TA) [2] (cf. Sect. 9.1 for an approach applying TA in combination with LSCs) provide modeling means for adding delays and timed conditions to the states and transitions of automata. Particularly, their efficient implementation by means of a simplified TA variant in the model checking tool UPPAAL [11,79] led to a wide range of approaches using TA as basis for the formal verification of timed behavior (see, e.g., [118] for a list of UPPAAL case studies). As the approaches mentioned before, specifying and analyzing TA either only consider the timed application behavior or requires to know and specify additionally the behavior of the platform and its timing effects. Thus, for applying TA for the purpose of schedulability analysis, the UPPAAL variant TIMES [4,5] enables to specify and analyze task models based on TA. However, this approach requires as much detailed knowledge of the final implementation or models of it that it can be applied only in later engineering phases, like conventional commercial-off-the-shelf-tools for response time analysis.

Conclusion and future work
In this paper, we presented an approach that enables endto-end response time analyses based on MSD specifications encompassing real-time requirements in the early RE phase of the development process. For this purpose, we introduced the Marte-based TAM profile that provides modeling means for platforms, their timing-relevant resource properties, and the allocation of MSD specifications to the platform models. Furthermore, we conceptually extend the event handling semantics of MSDs by introducing event kinds for the consideration of static and dynamic delays that occur during the software execution on a target platform. Finally, as the main contribution, we specified the operational semantics of platform-specific MSD specifications with extended event handling for the purpose of timing analyses. To this end, we applied the Gemoc approach enabling the automatic derivation of CCSL models from platform-specific MSD specifications based on our semantics specification. These CCSL models are executable in the simulative timing analysis tool TimeSquare, which also provides model checking features. Using an example application, we evaluated the approach with the automotive EBEAS example and outline the timing problems that we are able to identify on this abstraction level.
Our timing analysis approach enables to identify platforminduced real-time requirement violations in MSD requirements specifications that could otherwise be revealed only in late engineering phases through conventional timing analysis techniques. The TAM profile provides comprehensive modeling means to add timing-relevant platform-specific aspects to MSD specifications at an abstraction level suitable for RE. The extended event handling semantics for MSDs enables a more realistic consideration of the particular event occurrences and the delays in between. The specification of the MSD semantics for timing analyses encodes, in terms of CCSL and MoCCML, a subset of the conventional MSD semantics, the extended MSD event handling, and the platform resource properties' effects on the timing behavior. Particularly, the automatic computation and separation of the timing effects from their inducing resource properties enables the straightforward usage of platform models. Furthermore, the declarative semantics specification with Gemoc allows the flexible encoding of additional resource properties' timing effects or the adaption to other scenario-based notations. The model transformation generation feature of Gemoc Studio takes this specification as input and thereby reduces the effort of moving from MSDs to the CCSL formalism. The evaluation of the example application indicates the efficacy of the approach.
A promising starting point for future work is the size of the solution space, which arises out of the detection of a real-time requirement (cf. the discussion on the variety of potential fixes to a violation in the end of Sect. 7.1). Such challenges, where a large solution space exists and several constraints have to be considered, are subject to optimization questions and can be boiled down to a search problem in the solution space. Search-based software engineering [52][53][54] is a well-established software engineering field that applies meta-heuristic algorithms [39] to automatically solve such search problems. Similar to our previous work on automatically completing underspecified scenario models [110], the problem of finding real-time-feasible platform-specific MSD specifications could be encoded as input to a metaheuristic algorithm that has to incorporate the timing analysis results.
is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecomm ons.org/licenses/by/4.0/.