does there exist a port of QPC running on top of the automotive RTOS OSEK (or Autosar OS)? OSEK, especially with the BCC conformance classes, only supports so called "Basic Tasks". A basic task cannot block. It always runs to completion. On the other hand, an OSEK configuration is completely static and predefined at compile time. This means, that it is not possible to dynamically create new tasks, which were not predefined in the OSEK configuration. Still, as a run-to-completion OS, where all tasks share only one stack, this sounds like a good choice to support QPC.
Last edit: Stefan Schober 2017-03-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The QP frameworks provide a selection of built-in kernels. One of such built-in (natively supported) kernels is the preemptive, non-blocking, single-stack kernel called QK. This kernel supports exactly the "Basic Tasks", as defined in the OSEK/VDX RTOS specification. QK cannot be called "OSEK RTOS" only because it does not support the OSEK Implementation Language (OIL) and some other such cosmetic features. But conceptually, QK is exactly the run-to-completion kernel you are referring to. QK has been available since 2006. You can also read the related article "Build a Super-Simple Tasker" published in Embedded Systems Design in 2006.
Finally, since last year, QP include a built-in QXK kernel ("extended" QK), which supports both the "Basic Tasks" and "Extended Tasks" (capable of blocking) from the OSEK/VDX RTOS specification. This "dual-mode" QXK kernel has been designed specifically for situations where QP needs to be combined with traditional blocking code, such as middleware (TCP/IP, USB, file systems, GUIs) or legacy code.
--MMS
Last edit: Quantum Leaps 2017-03-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for this explanation. Yet we actually have two questions...
1) when developing solutions for our customers from the automotive industry, they often enough specify, that a certified OS is required. This means either OSEK or Autosar OS. We'd like to combine this with QPC's active objects.
2) From what we learned until now, the QK and QXK kernels are designed to support active objects implementing state machines. How can this design be utilized to execute "standard" task code (no AO/state machine)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) when developing solutions for our customers from the automotive industry, they often enough specify, that a certified OS is required. This means either OSEK or Autosar OS. We'd like to combine this with QPC's active objects.
The QP/C/C++ frameworks contain a Platform Abstraction Layer (PAL), which makes porting to 3rd-party RTOS kernels quite straightforward. The process of porting QP to 3rd-party RTOS is described in Section 8.3 of the PSiCC2 book.
2) From what we learned until now, the QK and QXK kernels are designed to support active objects implementing state machines. How can this design be utilized to execute "standard" task code (no AO/state machine)?
If your "standard" tasks require blocking (e.g., in-line waiting for time-delays or semaphores), you need to use a kernel that provides such mechanisms. Your choice includes a 3rd-party blocking RTOS, or the dual-mode QXK kernel.
On the other hand, if you can (re)write your "standard" task code in an event-driven fashion (one-shot event handlers that don't block), you can put such code into active object(s). Please note that the state machine associated with an AO can be trivial, meaning that it can consist of just one state that handles all events as simple reactions (called in the UML internal transitions).
--MMS
Last edit: Quantum Leaps 2017-03-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
does there exist a port of QPC running on top of the automotive RTOS OSEK (or Autosar OS)? OSEK, especially with the BCC conformance classes, only supports so called "Basic Tasks". A basic task cannot block. It always runs to completion. On the other hand, an OSEK configuration is completely static and predefined at compile time. This means, that it is not possible to dynamically create new tasks, which were not predefined in the OSEK configuration. Still, as a run-to-completion OS, where all tasks share only one stack, this sounds like a good choice to support QPC.
Last edit: Stefan Schober 2017-03-13
The QP frameworks provide a selection of built-in kernels. One of such built-in (natively supported) kernels is the preemptive, non-blocking, single-stack kernel called QK. This kernel supports exactly the "Basic Tasks", as defined in the OSEK/VDX RTOS specification. QK cannot be called "OSEK RTOS" only because it does not support the OSEK Implementation Language (OIL) and some other such cosmetic features. But conceptually, QK is exactly the run-to-completion kernel you are referring to. QK has been available since 2006. You can also read the related article "Build a Super-Simple Tasker" published in Embedded Systems Design in 2006.
Since 2014 there is also an official QP port to ERIKA Enterprise OSEK/VDX RTOS.
Finally, since last year, QP include a built-in QXK kernel ("extended" QK), which supports both the "Basic Tasks" and "Extended Tasks" (capable of blocking) from the OSEK/VDX RTOS specification. This "dual-mode" QXK kernel has been designed specifically for situations where QP needs to be combined with traditional blocking code, such as middleware (TCP/IP, USB, file systems, GUIs) or legacy code.
--MMS
Last edit: Quantum Leaps 2017-03-13
Thanks for this explanation. Yet we actually have two questions...
1) when developing solutions for our customers from the automotive industry, they often enough specify, that a certified OS is required. This means either OSEK or Autosar OS. We'd like to combine this with QPC's active objects.
2) From what we learned until now, the QK and QXK kernels are designed to support active objects implementing state machines. How can this design be utilized to execute "standard" task code (no AO/state machine)?
As described in the QP/C/C++ Reference Manuals, both QP/C and QP/C++ can work with virtually any traditional RTOS kernel (see http://www.state-machine.com/qpc/ports_rtos.html).
The QP/C/C++ frameworks contain a Platform Abstraction Layer (PAL), which makes porting to 3rd-party RTOS kernels quite straightforward. The process of porting QP to 3rd-party RTOS is described in Section 8.3 of the PSiCC2 book.
If your "standard" tasks require blocking (e.g., in-line waiting for time-delays or semaphores), you need to use a kernel that provides such mechanisms. Your choice includes a 3rd-party blocking RTOS, or the dual-mode QXK kernel.
On the other hand, if you can (re)write your "standard" task code in an event-driven fashion (one-shot event handlers that don't block), you can put such code into active object(s). Please note that the state machine associated with an AO can be trivial, meaning that it can consist of just one state that handles all events as simple reactions (called in the UML internal transitions).
--MMS
Last edit: Quantum Leaps 2017-03-13