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
toward secure embedded systems
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: toward secure embedded systems
Something that is a RTOS has to be deterministic by definition, what do you mean by ChibiOS being non-deterministic?
Giovanni
Giovanni
- alex31
- Posts: 374
- Joined: Fri May 25, 2012 10:23 am
- Location: toulouse, france
- Has thanked: 38 times
- Been thanked: 61 times
- Contact:
Re: toward secure embedded systems
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
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: toward secure embedded systems
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
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
- Posts: 384
- Joined: Sun Jun 12, 2016 4:10 am
- Location: Sydney, Australia
- Has thanked: 180 times
- Been thanked: 130 times
Re: toward secure embedded systems
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
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
Re: toward secure embedded systems
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.
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.
-
- Posts: 21
- Joined: Sat Feb 28, 2015 2:28 pm
- Location: Brno, Czech Republic
- Has thanked: 7 times
- Been thanked: 5 times
Re: toward secure embedded systems
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 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
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: toward secure embedded systems
Hi,
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
Dzarda wrote: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
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 26 guests