Architecture Modeling - SPES 2020

Architecture Modeling
of modeling artefacts in Orca is listed. The Orca tasks correspond to the components of the
logical perspective in the SPES metamodel that are allocated on the task components of the
technical perspective i.e. we have four tasks namely Command1, Monitor1, Command2
and Monitor2 building the two channels. For each channel, there exists a trigger node emitting
activation events with a certain period and jitter. Period and jitter are derived from the
assumptions of the triggered tasks Command1 and Command2 i.e. here both triggers produce
activation events with a period of 5 milliseconds. The communication between tasks is modeled
by signals in Orca which correspond to the communication components of the logical perspective
namely Com1ToMon1 and Com2ToMon2. The execution times for tasks were annotated
as attributes in the SPES model and translated to attributes of the Orca task nodes.
In the middle of the figure, the hardware architecture is depicted consisting of the two ECUs
ECU1 and ECU2. Each ECU has an ECUServer that implements the scheduler component
of the SPES model. Accordingly, each ECU-server contains two scheduler slots. Each task is
mapped to exactly one of these scheduler slots in the same way as described in Figure 5.20.
This mapping leads to the fact that each signal has to be transmitted using the bus component
CANBus which is part of the hardware architecture in Orca and offers a BusServer that
schedules two bus slots. The mapping of signals to bus slots is realized using messages. Each
signal that is not local is linked to a message and each message is mapped to a bus slot. The
mapping is not shown here explicitly.
The contracts of the SPES model are represented in different ways. First, as already mentioned,
the assumptions of triggered tasks are realized by their trigger nodes. The contracts
that define local deadlines for tasks or signals are realized by setting the deadline attribute of
the Orca nodes to the appropriate value. Contracts that define (non-local) deadlines over several
tasks or signals are modeled by end-to-end deadlines in the Orca model. There exist two
end-to-end deadlines, one for each channel, named according to the contracts they stem from.
Figure 5.23: Orca Deadline Violation
Using scheduling analysis, we now can check whether all contracts are fulfilled i.e. whether
all deadlines (local and end-to-end deadlines) of the Orca model are met. If there exists a
run such that a deadline is violated this is indicated by a red skull. For example, in Figure
5.22 the end-to-end deadline BSCUContractChannel1 and the local deadlines of the
92/ 156