Aus SDQ-Wiki
Palladio Addon (Liste)
Name Palladio-RT
Contacts Javier Fernández Salgado (
State Incubation
Is Stand-alone Analysis? No
Extends Analyses SimuCom
Extends Metamodels Annotations, New Notation Elements, New Views
Code Location

Short Summary

Palladio-RT enables modelling and analysing embedded software in PCM.


caption EPD-RT logo

Palladio-RT enables modelling and analysing embedded software in PCM. Palladio regular version is unable to model multi-tasking applications scheduled with a fixed-priority preemptive policy. This policy, however, is very common in embedded systems with real-time restrictions. The aim of this work is to provide developers an analysis approach for compositional design-level models which is capable of including fixed-priority preemptive scheduling (FPPS) policies. The solution consists of an extension to the PCM and a new performance analysis infrastructure that supports FPPS. The solution allows defining and simulating models in which each component is executed by a task with a specific priority. Additionally, each component can access shared resources using either immediate priority ceiling or priority inheritance protocols in order to avoid the priority inversion problem. The extension is limited to one scheduler per processor, and does not handle hierarchical nor partition scheduling techniques. This addon provides:

  • A scheduler that implements an FPPS policy, modelled as a new SchedulingPolicy instance called PriorityPreemptiveScheduler.
  • A resource instance of type ProcessingResourceSpecification, which implements the aforementioned policy. This instance has been called CPU PPS.
  • A new ResourceInterface called IPriority. With this interface, components are provided with a mechanism to request the use of a processing resource (i.e. the CPU) with a predefined priority.
  • A SimuCom extension to support new artefacts in PCM-RT.

The application of the transformation rules is illustrated with an use case example based on a real system, more specifically, the on-board software of a satellite payload that is currently being developed by the Space Research Group. The on-board software manages the Instrument Control Unit (ICU) of the Energetic Particle Detector (EPD), which will be launched as part of the Solar Orbiter mission of the European Space Agency (ESA) and the United States National Aeronautics and Space Administration (NASA). The validation of the newly defined analyser has been done by modelling different FPPS basic scenarios. Some of them involve access to shared resources using the immediate priority ceiling or priority inheritance protocols. For every scenario, the response times obtained by simulation have been checked against the expected theoretical results. Finally, in order to vali- date the performance analysis solution on a real system, the Palladio model of the software of the ICU of EPD (ICUSW) has been constructed and the coherence between the simulated results and the theoretical ones has been verified.

Download files

Version 3.3

The version of Palladio-RT builds upon [[PCM_3.3] Palladio 3.3]. As it has been developed and tested for Palladio 3.3, we recommend you use this version of Palladio.


Palladio-RT Addon

Use case ICUSW

Palladio-RT Case Study

Uses case introduction

The PCM model of the ICU software (ICUSW) includes the structure of the components, the topology and the established interface, the component subscription to interrupt and timing services throught a specific component termed as component runtime and the behavioural specification of them all. Each of these aspects is covered below in the corresponding section.

Component Structure

The ICUSW composition structure is depicted in Figure 1. The system is composed of five components instances EPDManager, HKFDIRManager, SensorTMManager, BKGTCExecutor, EDROOM RT. A shared resource called SCTxChannelCtrl works as a stand-alone component that is accessible from the rest of components. The role of each one of these components is detailed below:




this component periodically retrieves the telecommands, executing the prioritized ones — those that must meet a hard real time constraint—. The non-prioritized telecommands are forwarded to other components, depending on their related service. It also manages critical events, including those related to software exceptions of the ICU.


this component periodically performs the actions concerning housekeeping and Fault Detection, Isolation and Recovery (FDIR). It is responsible of ensuring that critical events detected during these actions will be notified to EPDManager. Finally, it also executes the housekeeping service telecommands forwarded from EPDManager.


this component periodically retrieves the EPD sensors telemetry, ensuring that the science data baud-rate is under the specified limits. It also detects and notifies the EPDManager the critical events associated to the sensors’ telemetry. Finally, it executes the Science service telecommands forwarded from the EPDManager component instance.


it executes the background telecommands received from EPDManager.


it is a shared resource that controls the transmission buffer of CCSDS packets from the ICU to the spacecraft. The rest of components access this resource in order to queue the telemetry packets that must be sent to the spacecraft. The transmission of the queued packets is later handled by dedicated hardware.


this component manages the timing and exception subscriptions of the whole components. It emulates the CPU demands of interruption management strategies as bottom halves.

Communication Specification

Three different interfaces define the communication between components

interface that defines timmign and exception subscriptions to Runtime component (EDROOM RT).
interface to exchange telecommands.
interface to keep telemetry packects.
system delegation interface with the programed external interruptions.

Interrupt and Timing Subscriptions

Components can subscribe to interrupt/exception and timing services that are provided by a run-time library called the EDROOM RT. Component subscriptions are specified by means of a specific type of port that allows the transformation of timing or interrupt/exception events into messages. The implementation of the provided services is divided into a top-half and a bottomhalf. The top-half part corresponds to the interrupt handler that, in the case of timing ports. The bottom-half is itself a task that receives the signal from the top-half and transforms the event into a message that is later inserted in the queue of the subscribed component. This division is necessary because the queue of a component is a shared resource that cannot be accessed from within an interrupt handler.

Triggering patterns of the events

In follwoing table is shown the activation patterns of the different events.

Task Event Triggering Pattern Period / Minimal Inter-arrival Time
EPDManager (Prio telecomands) TCRetrieving (timing port) Bursty 1000 ms (min. inter-arrival time) + 10 (max. events) + 1 ms (inter arrival)
EPDManager (Service telecomands) TCRetrieving (timing port) Bursty 1000 ms (min. inter-arrival time) + 8 (max. events) + 1 ms (inter arrival)
EPDManager ICUException Sporadic 100.000 s
(exception port)
HK_FDIRManager Housekeeping Periodic 1 s
(timing port)
HK_FDIRManager FaultDetection Periodic 500 ms
(timing port)
SensorTMManager SensorTM Retrieving Periodic 1 s
(timing port)

Contact Information

Javier Fernández Salgado

Personal de investigación en formación



Escuela Politécnica Superior

Ctra. Madrid Barcelona Km 33,600

28805, Alcalá de Henares, España

Tel./Fax +34 91 885 6907