Ada provides tasking. Why then use Ada with an RTOS like VxWorks?
If you consider an RTOS that provides the same services as Ada does (via its Run-Time System, RTS), there is no reason, in principle.
If your Ada application does not need full Ada tasking, and your system is resource-constrained (memory is tight and/or processing time is tight) the lightest Ada RTS from your Ada vendor may be heavier than the lightest RTOS you can find that just meets the needs of the application. However, this is less likely today, with the Ravenscar and Jorvik tasking profiles and corresponding lighter-weight RTSs.
If your Ada application needs services that exceed the standard Ada RTS, for example networking services, it may be easier to use one of the larger RTOSs like VxWorks with such services built in, rather than implement those services in Ada on the Ada RTS. However, many embedded systems are now powerful enough to support an Ada RTS on top of a complex real-time OS such as VxWorks, giving you the best of both worlds.
Finally there may be verification, qualification/certification and security requirements that affect the choice. For example, if your application must be certified, but your Ada vendor has not certified an RTS for your platform, it may be faster and cheaper to find an RTOS that has been or can easily be certified on that platform. For another example, if your system requires time/space separation between processes, the Ada RTS is not sufficient and some “separation kernel”, or an OS with a process concept, is needed.
Why would I bother with the RTS in this case?
Also, thank you very much for the in-depth explanation!
Two reasons: Firstly, the Ada RTS and Ada tasking provide higher-level services than a typical RTOS, making for easier and safer programming. For example, protected objects instead of semaphores or message queues. Secondly, if your Ada program uses Ada tasking, you can run it on any Ada platform, for example a PC. I have often tested multi-threaded embedded applications on PCs, relying on the portability of Ada tasking. Of course this portability also reduces your dependency on your choice of RTOS.
Ada tasking model is very interesting.
Beware that current Embedded Ada RTS (Ravenscar and Jorvik) implement limited tasking functionalities compared to desktop full RTS.
Yes, Ravenscar and Jorvik are subsets of full Ada tasking, so a Ravenscar/Jorvik program can be run on a full Ada system, but not vice versa.
However, it is certainly possible to provide a bare-machine Ada RTS with full tasking for embedded use, provided the embedded system has enough resources. I don’t know if e.g. AdaCore currently supplies such full embedded run-times.
From 2000 to 2010, when I retired, we implemented in full Ada over VxWorks (on the target) or, with no application change, on Windows (for testing only).
GNAT.Sockets was fully implemented over VxWorks.
The question of hard vs soft RTOS also comes into play. I don’t think the Ada standard tasking is considered hard real time???
I’m surprised your employer would use vxworks. I guess it is written in C, considering the CVE overflows etc. that it has had.
It was written in C mostly yes (at least the versions I am familiar with were). There were various already certified versions of it, so it was a pretty common pick in certain industries.
The system had no Internet connections (it went to sea on warships, and its purpose was stand-alone anyway)
The Ada RTS supports hard real-time applications. The Jorvik and Ravenscar subsets make it easier to prove important real-time properties, but even the full Ada run-time is designed to support hard real-time applications. Note that not every implementation of the Ada RTS is able to support hard real-time, but those that support the Real-Time Annex are required to provide various metrics which should enable the programmer to make assessments of real-time schedulability.
Ada tasking is certainly designed to allow hard real time – preemptive priority scheduling, ceiling priority inheritance, and so on. Actual performance of course depends on the platform and on the RTS implementation. For example, in my last job developing on-board SW for spacecraft, we implemented systems with several tens of tasks, with task deadlines down to 1 ms, and less for interrupt handlers, on bare-board SPARC processors with clock frequencies below 100 MHz, using Ravenscar RTSs from AdaCore and others. Worked well.