toward secure embedded systems

[alex31]

Hello,

ChibiOS API offers asynchronous, non-deterministic way of programming embedded systems using the task paradigm. The trend seems to use synchronous systems, generated code, using tools like "lustre", "esterel", or expensive complete frameworks like Asterios from krono-safe to achieve robust systems that can be formally proved. I wanted to know the thoughts about that from you, embedded developers, ChibiOS authors and contributors. Is there a possible soft path between traditional asynchronous RTOS and synchronous one, or do we have to undergo a brutal change ?

Alexandre

[Giovanni]

Something that is a RTOS has to be deterministic by definition, what do you mean by ChibiOS being non-deterministic?

Giovanni

[alex31]

Something that is a RTOS has to be deterministic by definition, what do you mean by ChibiOS being non-deterministic?

In the synchronous world, the scheduling is statically calculated at "compilation" each task has a predefined slot of time that it can use or not, and task are called in a static order. That, and some others properties of synchronous systems permit to do some formal proof that the system will always have desired behavior.

ChibiOS, as all other asynchronous RTOS, is not deterministic in the sense that you cannot predict, in which order task will be scheduled, it depends on the system states and inputs.

I know very few about the synchronous world, but I think it's something I have to explore since many avionic systems that have to be certified use this paradigm. Since many embedded programmers have to face these problems : design hardened and certified systems, I would ask the people knowing this field here. I don't want to use closed system like asterios, so T wanted to know if someone has already think about having mixed system to introduce synchronous paradigm in classical RTOS like ChibiOS.

Alexandre

[Giovanni]

Any RTOS is able to operate synchronously using pre defined time slots and similar. In RT you could use virtual timers and schedule everything in fixed time slots without even using threads.

The problem is that any real embedded applications is handling asynchronous external events, a pure synchronous approach would degenerate into a "poll any possible asynchronous event source using predefined time intervals and process those using time-constrained code".

Deterministic for sure but good luck into doing real work using those constraints, just think at all possible interrupts sources in your average MCU, you should not have asynchronous IRQs by definition, ISRs are just asynchronous hardware-triggered tasks and those DO affect your timings.

Giovanni

[FXCoder]

This thread brought a smile to my face...
The synchronous mode described is very reminiscent of circa 1970 Single interrupt and multiple Priority Level OS.
The system interrupt takes you to the top of the "application" priority level for normal tasks.
As each Priority Level is "completed" (all tasks in a job list for that PL run in a fixed order) then the system drops down to next lower PL.
Rinse and repeat for each PL until reaching "base level" where all remaining (low priority) tasks just ran in a loop until the next system interrupt.

Everything old is new again?
--
Bob

[MGeo]

This guy does some nice writing with comprehendible examples and a comparison of event and time triggered architectures.
https://www.safetty.net/technology

This company has many examples of real work being done https://www.tttech.com/markets/aerospace/

http://itech.fgcu.edu/faculty/zalewski/ ... MODULE.pdf

Questionable benefits for simple, non-safety critical applications. TT enforces limitations on the implementation in the name of determinism, and really is aimed at more critical applications.

[Dzarda]

Although this thinking does resonate with me, I'm not sure about bending a preemptive RTOS towards safety-critical synchronous operation etc. I'd advise a look at Protothreads, C++20 Coroutines or Rust's async/await (Rust seems to have gone furthest in this area, speaking of native code. C# or Python also have this.) This way your code is cut up statically, at compile time, in places you control.

@giovanni AFAIK this does really mean that you want interrupts disabled and you'd be polling the world. You're trading flexibility, latency, performance for more determinism, less cyclomatic complexity, and all that stuff.

Think automation, PLCs, fighter jet control busses

[Giovanni]

Hi,

This way your code is cut up statically, at compile time, in places you control.

This is already the case with both RT and NIL, all data positions are decided at link time and all OS data is encapsulated into a single structure named "ch" for RT and "nil" for NIL. You can control where to place it and also place guard pages around it using the MPU if you need that. Stacks can have guard pages, there is runtime self-diagnostic code and more of usual safety-oriented features.

NIL goes even further, it does not even have dynamic structures like lists or queues, it is all static finite arrays and single depth pointers. It trades performance for a much simpler internal architecture.

Both have dynamic extensions, allocators and the factory, but those sit on top of the static cores and are optional, you can disable those from the image entirely.

I have not yet started a certification process because the costs involved but both have been designed with FuSa in mind.

Giovanni