What is CPAL?

Our ability to write software is a key to innovation

CPAL as a Design Exploration Platform

CPAL is meant to model, simulate and validate the functional and timing behaviour of embedded systems, and
enable you to make design choices based on evidence from simulations or formal verification techniques. The CPAL editor shows the functional architecture of a system (top-left), the FSM describing the logic of a process (bottow-left) and the scheduling of the processes as seen during a simulation.

CPAL can be part of a co-simulation environment, for instance it can be coupled with the RTaW-Pegase network simulator and serve as high-level programming language to develop models of communication layers, run-time environments and applications in order to simulate complete embedded systems. It also runs within Matlab/Simulink® to execute control programs.

CPAL as a Real-Time Execution Engine

CPAL programs — also called models because of the high-level abstraction provided by the language — can be executed directly by an interpretation engine without the usual code generation and compilation phases. CPAL programs are developed in simulation mode on a workstation and the exact same code can be run on an embedded board with the same run-time behavior. Once coded and validated, you just have to upload the CPAL program on the target and you are done!

Unlike what is typically done in Model-Based Design where execution is achieved by generating code from a model, and then compiling it, CPAL programs are executed by an interpretation engine. The interpreter can run on bare hardware, that is without the need for an operating system — what we call Bare-Metal Model Interpretation (BMMI). BMMI helps reducing the memory footprint and avoiding errors that can be introduced throughout the design flow (e.g., at code generation or compilation stage, or errors at the OS level). BMMI eases verification too because the model is what is actually executed, and not code generated from the model, which cannot have the exact same semantics as the model and which, in addition, relies on OS services and external libraries. The memory footprint of the CPAL execution engine is in the 10s of kilobyte range depending on the execution platform.

Model interpretation is not something new, several interpretation-based runtime environments, have been certified at the highest criticality levels and deployed at large scale in railway interlocking systems over the last 20 years at SNCF and RATP in France, and in the UK and other countries through the WESTLOCK™ interlocking system from Westingshouse. These technologies have proven to be technically successful in the sense that 100s of millions of people rely on them on a daily basis. Although these technologies are specific to interlocking systems, our belief is that a similar approach, with a programming language providing the right abstractions and the support of modern execution platforms, facilitates and speeds up the development of provably safe and secure CPS.

Simplicity, correctness and productivity in mind

CPAL has been inspired by a number of diverse languages such Eiffel, MISRA C and Erlang, model-based design products as Matlab/Simulink™ and Scade™, simulation environments such as Opnet™, verification frameworks such as Promela/Spin and more generally what is usually referred to as the synchronous programming approach (Giotto, Lustre, Signal).

However, CPAL has been designed with the requirements to remain a small, simple and unambiguous language. CPAL does not provide constructs that are hard to handle, or that lead to indecipherable code. To increase the developer's productivity, CPAL offers PAL offers high-level abstractions that are natural and well understood to model CPS such as for instance native support for

• Real-time scheduling mechanisms: processes can be activated with a user-defined period and offset relationships, or upon the occurrence of some external events.
• Finite State Machines (FSM): the logic of a process can be defined as a Finite State Machine (FSM) — possibly organized in a hierarchical manner — where code can be executed in the states, or upon the firing of transitions.
• Communication channels to support control and data flow exchanges between processes, and read/write to hardware I/O ports with well-defined policies (FIFO or LIFO buffering, data overwriting, etc).

processdef MonitorProc(in uint8: aPort, out bool: alarm)
{
  const uint8: threshold = 30;
  state NormalMode{ 
  /* ... */
  } 
  on (aPort > threshold) {
    alarm = true;
  }to AlarmMode;
   
  state AlarmMode {
    /* ... */
  }
  after (2s) if (aPort < threshold) to NormalMode;
}

var uint8: sensor#1; /* mapped to some I/O port */ 
var uint8: sensor#2; /* and updated upon activation of the processes */
var bool:  first_alarm  = false;
var bool:  second_alarm = false;

/* Instantiation of periodic monitoring processes*/
process MonitorProc: p1[500ms](sensor#1, first_alarm);
/* Second process is only executed when first_alarm is true */
process MonitorProc: p2[100ms][first_alarm](sensor#2, second_alarm);

Since the language is simple and the abstractions are natural for the domain of CPS, developing CPAL programs is quick and intuitive. In addition, both the FSMs and the data-flow between processes can be visualized graphically in the CPAL-Editor enabling some verification and providing a convenient way to explain a program, or part of, to all stakeholders of a project.

Further information ?