Model-Based Design and Timing: From Simulink and AADL Models to Verified Real-Time Code

Model-based design promises that engineers can develop and verify control algorithms and system architectures as models, then generate the implementation automatically. For functional behavior the promise largely holds. Simulink models are simulated, tested and turned into production C code across automotive, aerospace and industrial systems. Timing is harder. A simulation runs in logical time, where computation takes zero time and every block executes exactly on its sample hit. The generated code runs on a real processor, where it competes for CPU time, gets preempted, and finishes at varying moments. Unless the design flow deliberately bridges the two, the timing assumptions validated in the model can quietly fail to hold in the code.

This article covers how multi-rate Simulink models map onto real-time tasks, how AADL captures architecture-level timing, how the Logical Execution Time (LET) paradigm keeps model and implementation consistent, and how to integrate WCET and schedulability analysis into a model-based workflow.

The timing gap between model and code

Dataflow and block-diagram tools such as Simulink rest on a synchronous abstraction. At each sample hit, blocks compute their outputs instantly from their inputs. The synchronous languages behind SCADE (Lustre) and Esterel make the same assumption explicitly. The abstraction is what makes models analyzable and simulation deterministic, but it hides three things that matter on the target:

• Execution time. A control law that “runs at 1 kHz” needs CPU time every millisecond, and that time has to be bounded. See WCET analysis methods.
• Preemption and ordering. When several rates share a CPU, a slow task can be interrupted halfway through reading data that a fast task is updating.
• Latency. The time from sensor input to actuator output in the code is usually longer than in simulation. Control engineers need to know by how much, because added delay erodes stability margins, as discussed in timing in flight control.

Model-based timing engineering keeps the model’s semantics true in the implementation, or at least makes any differences known and bounded.

Multi-rate Simulink models and Embedded Coder

A typical controller model contains blocks at several sample times: a fast inner loop, a slower outer loop, and a slow supervisory or diagnostic function. Simulink requires sample times in a multi-rate model to relate to a fundamental base rate, normally the fastest. Slower rates are integer multiples of it.

Single-tasking versus multitasking

Code generated with Embedded Coder can run in one of two execution modes:

• Single-tasking: all rates execute inside one step function called at the base rate. Slower rates simply run on the ticks where they are due. This is simple and deterministic, but the base-rate step must fit everything that can coincide in a single tick, including the slowest rate’s full workload.
• Multitasking: each rate becomes a separate task, with one generated entry point per rate (for example model_step0(), model_step1()). Priorities are assigned rate-monotonically: the faster the rate, the higher the priority. Slow, long computations can then be preempted by fast loops. This is the standard way to make a multi-rate model fit on a single core.

Rate-monotonic assignment gives you a well-understood analysis framework for free. Once you know the WCET of each rate’s step function, the task set can be checked with utilization bounds or exact response-time analysis. For background on why rate-monotonic ordering is optimal among fixed-priority schemes for implicit-deadline tasks, see Rate Monotonic vs Earliest Deadline First.

Rate Transition blocks

In multitasking mode, a signal that crosses between rates becomes shared data between tasks of different priorities. Simulink requires these crossings to go through Rate Transition blocks, which can be configured to guarantee data integrity and deterministic transfer:

• Fast to slow: the block behaves like a zero-order hold. The slow task sees the value the fast task produced at the start of the slow period, regardless of how preemption interleaves the two.
• Slow to fast: the block behaves like a unit delay at the slow rate. The fast task sees the slow task’s output from the previous slow period. This guarantees determinism and adds up to one slow period of latency.

That deliberate delay on slow-to-fast paths is essentially the same idea as Logical Execution Time, described below. Determinism is bought with known latency.

The generated scheduler

For bare-metal targets, Embedded Coder can generate an example main program. Its core is a periodic interrupt handler that runs the base rate, then dispatches due sub-rates and detects overruns. Conceptually:

// Conceptual structure of a rate-monotonic step dispatcher for a multi-rate model
volatile bool running[N_RATES];

void base_rate_isr(void) {             // timer interrupt at the base rate
    if (running[0]) { overrun_handler(0); return; }
    running[0] = true;
    model_step0();                     // fastest rate, highest priority
    running[0] = false;

    for (int r = 1; r < N_RATES; r++) {
        if (rate_due(r)) {
            if (running[r]) { overrun_handler(r); continue; }
            running[r] = true;
            enable_interrupts();       // allow faster rates to preempt
            model_step(r);
            disable_interrupts();
            running[r] = false;
        }
    }
}

On an RTOS or AUTOSAR platform, you would usually map each rate’s entry point onto an OS task or runnable instead. Simulink’s export-function modeling style supports this, leaving scheduling to the platform. Either way, the timing claim rests on knowing each entry point’s WCET. Embedded Coder’s software-in-the-loop and processor-in-the-loop (PIL) modes can profile the execution time of generated code. PIL measurements on the real target are a useful early input, though they don’t replace a WCET argument.

AADL: timing at the architecture level

Simulink describes what a component computes. The Architecture Analysis & Design Language (AADL), standardized by SAE International as AS5506, describes how software components are deployed onto an execution platform. AADL grew out of the earlier MetaH language and was first published in 2004, with several revisions since. It models software components (processes, threads, subprograms, data) and hardware (processors, memory, buses, devices). Properties capture timing, and bindings say which threads run on which processors and which connections use which buses.

-- Abbreviated AADL: a periodic controller thread bound to a processor
thread Controller
  features
    state_in : in data port;
    cmd_out  : out data port;
  properties
    Dispatch_Protocol      => Periodic;
    Period                 => 5 ms;
    Compute_Execution_Time => 0.4 ms .. 1.2 ms;
    Deadline               => 5 ms;
end Controller;

process implementation FlightCtl.impl
  subcomponents
    est : thread Estimator;
    ctl : thread Controller;
  connections
    c1 : port est.state_out -> ctl.state_in {Timing => Delayed;};
end FlightCtl.impl;

system implementation Avionics.impl
  subcomponents
    cpu : processor Core;
    app : process FlightCtl.impl;
  properties
    Actual_Processor_Binding => (reference (cpu)) applies to app;
end Avionics.impl;

With threads, execution-time ranges, periods and bindings declared, tools can analyze the architecture long before code exists. OSATE, the open-source AADL tool environment from the Software Engineering Institute, provides end-to-end flow latency analysis and resource budget checks. Schedulability analysis can be run through tools such as Cheddar, and code generators such as Ocarina target several RTOS platforms. The Timing property on connections (sampled, immediate or delayed) makes the data-transfer semantics explicit, which is the architectural counterpart of Simulink’s Rate Transition choices. Annexes extend the core language with behavior models, error models for safety analysis, and ARINC 653 partitioning.

Logical Execution Time: making timing deterministic

The Logical Execution Time (LET) paradigm was introduced with the Giotto language by Henzinger, Horowitz and Kirsch in the early 2000s. It separates when a task communicates from when it actually computes. Each task reads its inputs at the start of its logical execution interval (its release) and makes its outputs visible at the end (typically its period or deadline). The task can execute at any point in between.

// LET semantics for a periodic task with period T
at release time r_k:
    in_k = snapshot(inputs)           // logical read instant
schedule compute(in_k) anywhere in [r_k, r_k + T)
at time r_k + T:
    publish(out_k)                    // logical write instant, never earlier

Because communication happens only at those fixed instants, the observable behavior is the same whether the task finishes early or late, on one core or several, under any valid schedule. If the platform meets every deadline, the implementation matches a model that uses the same semantics. The cost is a fixed latency of one LET interval per hop. LET has drawn particular interest in automotive multicore software, where it gives deterministic cross-core communication. It also matches how the delayed connections in AADL and the deterministic rate transitions in Simulink already behave. On multicore, LET pairs naturally with the partitioning approaches in multicore real-time scheduling.

Integrating timing analysis into the model-based flow

The right time to think about timing is at every stage, not only at the end. A practical workflow looks like this:

The essential step is the feedback loop. Measured or analyzed WCETs replace the initial budgets in the architecture model, and schedulability and latency are re-verified. If a budget is exceeded, the choices are to optimize the algorithm, change rates, rebind threads, or renegotiate the requirement. Our schedulability calculator is useful for quick what-if checks on rate assignments. For a production program, our WCET and timing analysis service can supply the target-level evidence.

Standards and tool qualification

In avionics, DO-331 supplements DO-178C with objectives specific to model-based development, including model coverage and the relationship between models and requirements. Automotive projects following ISO 26262 have similar expectations for model-based software. When generated code isn’t fully reviewed by hand, the code generator or the verification tools may need to be qualified. SCADE’s KCG code generator is qualified for use in certified avionics, and MathWorks offers qualification and certification kits for its tools. Timing evidence (WCET and schedulability) is still required for the generated code on the actual target.

Components, contracts and the FRESCOR perspective

Model-based timing gets much easier when components carry their timing properties with them and the platform can enforce them at run time. The original FRESCOR research project worked in this direction. Its plans included a component-based framework in which components declare timing properties, and an interface to Matlab/Simulink so that model-based designs could be connected to its contract-based scheduling framework. The project overview and expected results pages in our archive describe these goals. Rapita Systems, whose RapiTime tool appears in the table above, was one of the project partners. The underlying idea, that a component’s resource needs become a negotiable, enforceable contract, is explained in contract-based scheduling explained. It extends naturally to mixed-criticality systems, where models of different assurance levels share a platform. Teams adopting this style can use our contract-based scheduling workshop as a hands-on introduction.

References and further reading

1. Architecture Analysis & Design Language — Wikipedia
2. SAE AS5506, Architecture Analysis & Design Language (AADL) — SAE International.
3. OSATE — Open Source AADL Tool Environment — Software Engineering Institute, Carnegie Mellon University
4. Embedded Coder — MathWorks
5. Simulink — Wikipedia
6. T. A. Henzinger, B. Horowitz, C. M. Kirsch, “Giotto: A Time-Triggered Language for Embedded Programming,” Proceedings of the IEEE, 2003.
7. P. H. Feiler, D. P. Gluch, Model-Based Engineering with AADL, Addison-Wesley, 2012.
8. DO-178C (including DO-331 supplement) — Wikipedia