Palladio-RT
| Name | Palladio-RT |
|---|---|
| Contacts | Javier Fernández Salgado (https://srg.aut.uah.es/) |
| State | Incubation |
| Is Stand-alone Analysis? | No |
| Extends Analyses | SimuCom |
| Extends Metamodels | Annotations, New Notation Elements, New Views |
| Code Location | https://svnserver.informatik.kit.edu/i43/svn/code/Palladio/Addons/Palladio-RT/ |
Short Summary
Palladio-RT enables modelling and analysing embedded software in PCM.
Documentation
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.
Plugin
Use case ICUSW
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:
- EPDManager
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.
- HKFDIRManager
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.
- SensorTMManager
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.
- BKGTCExecutor
it executes the background telecommands received from EPDManager.
- SCTxChannelCtrl
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.
- EDROOM-RT
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
- TimmingExceptionEDROOM
- interface that defines timmign and exception subscriptions to Runtime component (EDROOM RT).
- Command
- interface to exchange telecommands.
- SharedResource
- interface to keep telemetry packects.
- ExceptionTimming
- 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
jfernandez@srg.aut.uah.es/Javito1@gmail.com
Personal de investigación en formación
EL-31
SPACE RESEARCH GROUP
Escuela Politécnica Superior
Ctra. Madrid Barcelona Km 33,600
28805, Alcalá de Henares, España
Tel./Fax +34 91 885 6907