www.altreonic.com

Professor emeritus Charles Anthony Richard Hoare has passed away at the age of 92. Known to many as C. A. R. Hoare, or Tony Hoare, he was one of the great minds in the domain of software engineering. Altreonic's history that has it roots in the late 1980's, was essentially based on Hoare's CSP process algebra. CSP stands for Communicating Sequential Processes. Here's my personal road that followed. Note that I am an engineer, not an academic. An engineering approach is to make something that works in practice but following sound principles that academics have developed.

My initial exposure to software was while studying as an engineer in the domain of electronics and applied mechanics. We had an old IBM-360 and we learned to program in Algol-68 and Fortran. Later, as PCs became affordable, Pascal was added. Meanwhile, Tony Hoare had developed CSP, which later on was adopted as the conceptual framework for a unique processor, called the Transputer (ex-INMOS).  At the time it was very different from the mainstream Intel processors. The transputer was a RISC-like CPU with unique support for software and hardware concurrency. It natively supported small processes and inter-processor communication. As it had a small register set and hence context process switching was fast and interprocessor communication had a low latency. For programming the unique occam language was developed. Occam was a direct implementation of a subset of CSP with processes and communication channels. 

Just before that time, I had envisioned the concept of a parallel computer (using optical communication). With hindsight, building a parallel computer is easy. What's hard is how to program it in an efficient and scalable way.  At that time the focus was on data-parallel programming, think about image processing whereby a large image is split in N chunks and each processor executes the same code on its chunk, providing a theoretical speed-up with a factor N. In reality, "grain size" and "communication latency" determine the unavoidable overhead. The idea was to use the principle of a spreadsheet. References from one cell to another cell can be seen as micro-messages. This worked well and we had the traditional Mandelbrot and equation of Laplace demos. 

Around that time, INMOS put its transputer on the market. That was a great opportunity to put the ideas in practice. The development kit had 4 transputers and came with an occm compiler. I bought such an (expensive) kit and that was the start of a long story. First of all, although occam-1 was very simple and even had only 1 datatype (the byte), programming in occam had a steep learning curve to get working parallel programs. The compiler was unforgiving but if you got it compiled, the program would often run flawlessly. The other issue was not to have any deadlocks. After 1 month of error and trial I attended Professor Peter Welch's occam course and on the second day, the mental AHA switch happened. I watched my brain translating the simple exercise specification in "IF-THEN-ELSE" statements and realised that this was wrong. I also realised that this was the consequence beind trained in programming using sequential languages whereby one tries to keep track of the whole state-space. The switch to concurrent thinking is to look for the actions in the specifications and then seeing how they are related. Actions become local processes and relationships become communication channels. Once, that mental switch is made, there is no way back. It is the natural way to analyse problems.

I then learned that this is the essence of Hoare's CSP. I summarise it here: 

• No Shared State: Processes in CSP do not share memory; they communicate exclusively through explicit, synchronized channels.
• Synchronous Communication: A process sending a message (channel writer) must wait until another process receives the message (channel reader), providing built-in synchronisation.
• Process Algebra: CSP provides mathematical methods to describe and verify the behaviour of complex systems composed of simpler, smaller processes.
• Formalism: CSP uses mathematical modeling to prevent concurrency errors such as deadlocks, livelocks, and infinite overtaking.

Most importantly Hoare's was one of the pioneers who aimed for a Correctness by Construction: The goal of CSP is to enable the design of (concurrent) systems that are guaranteed to be correct through formal mathematical proof rather than just testing. 

While I consider occam almost an obligatory passage for learning concurrency (and how to control it), occam and the transputer were still rather academic ventures. Occam had rather elementary semantics and the transputer did round-robin scheduling with 2 levels of priority. Real-world (embedded) programming requires flexible programming languages and real-time priority based scheduling. Hence, shortly after the C-compiler was introduced we developed a small RTOS with priority based scheduling on the transputer (2001). Moreover, we introduced the concept of "Virtual Single Processor" programming by allowing to call the RTOS services anywhere in a network. Essentially, the channels inherited the semantics of the RTOS (like semaphores, queues and mailboxes) but network-wide routing was also  part of the RTOS kernel. Essentially, the RTOS was a scheduler on top of a packet switching network. A major change was that the semantics were made "distributed". No more passing of pointers, but passing by value , exactly as CSP mandates. This became the Virtuoso RTOS that later on was ported to other targets like the parallel DSPs of Texas Instruments (C40, C6xx) , Analog Devices (Sharc) but also microcontrollers, PowerPC and some exotic DSPs. On these targets the communication layer was a lot more complex to implement than on the transputer. 

In 2001, Wind River Systems acquired the IP but never managed to turn it into a successful product. I blame it on the shared-memory syndrome. In the end it was open-sourced and now lives on (single processor) with a more Posix-like API under the name of Zephyr. 

After this event, I increasingly started thinking about how one could develop correct by design software. Even if the Virtuoso RTOS was subjected to rather demanding Monte-Carlo type stress tests before release (DSPs in particular have a lot of concurrency in the hardware), sometimes an issue would still pop-up years later for the simple reason that the user programmed his application in an unexpected way. This is one of the reasons why we kept the service names very readable, expressing what they did. One example that we encountered was a memcpy whereby the data could be overwritten if the originator did it too fast. The memcpy was implemented with DMA. DMA engines operate independently from the CPU and need some time to copy data. Hence the service became memcpy_W, a blocking call that waited for the DMA to have copied the last byte. On a sequential processor this is not an issue because the copying is done by the CPU in a sequential loop. As a result, all services were developed in a blocking (_W), non-blocking (_NW) and blocking with time-out version (_WT).

Out of these experiences, we started to look at developing a new Virtuoso from scratch but this time using formal techniques. This was completely new for us and it was not so easy to figure out if this was the path to follow.  Formal techniques were (and still are) very much a research topic, only applied in very specific cases. And being very mathematical in nature, formal techniques are often applied by PhD level experts. I remember a lecture by professor Patrick Cousot whereby he showed how abstract interpretation was able to find an overflow in a loop that could happen after 300 hours in a formally proven flight software. I was flabbergasted but this is one of the experiences that convinced me to try the formal path. 

But how? And with what tools? The formal community seemed to have two approaches. The first is the abstract interpretation path, whereby axioma's are constructed and applied to a piece of software. The engineer then has to develop a proof that the software has no residual errors. The other approach is formal modeling whereby a formal model is developed and a model checker verifies if the model can't reach an illegal state. The abstract interpretation road didn't seem to be the one to take. Not only were exceptional skills required, it assumes the existence of a software to be be checked. Formal modeling seemed to be the best approach as our goal was to redevelop the RTOS from scratch. Guiding lines were our experience: a CSP derived program model as implemented in the Virtuoso RTOS, distributed semantics, prority-based system-wide scheduling and correct by design.
Two options remained: Spin and Leslie Lamport's TLA+. Professor Boute was our coach and TLA+ was selected. To make a long story short (the project took 3 years but was not a full-time activity), while there was a steep learning curve, we ended up doing things a bit differently. TLA+ was used to model and verify the architecture and the semantics, not the source code.  That would have been a mistake as software sources evolves. The result was an RTOS kernel that implemented the concept of "Interacting Entities". The entities were mainly "Tasks" (processes in CSP) and the interactions the kernel services connecting the Tasks through intermediate" so-called "Hubs" (channels in CSP) but with much richer semantics, including asynchronous communication. The hubs and the packet switching also played a crucial role in the new architecture. The benefits were scalability, efficiency and maintainability. Unexpectedly, the code size shrank considerably, about a factor 10. The whole kernel now fitted in about 10 kb (this is very much processor dependent). The project was called "OpenComRTOS" and today lives on under the name VirtuosoNext. The current implementation supports fine-grain space partitioning and even allows to recover in micro-seconds from faults like overflow exceptions. The project was documented in a book (Formal Development of a network-Centric RTOS published by Springer).

The project also opened a road towards trustworty system design. It enhanced the capability to think in abstract terms about systems. In a small electric vehicle, the "Interacting Entities" concept was implemented in the drive-by-wire software of the 4 independent wheels. In the GoedelWorks project we sought to achieve "correct by construction" for systems using meta-modeling of the project entities but also of the development processes followed. A key element was the dependency graph that allowed to keep track of the impact of changes. Finally, the ARRL (Assured Reliability and Resilience Level) concept we introduced the concept that the ultimate goal of trustworthy systems engineering is not only to be fault-tolerant, secure or safe but to survive, being able to function as intended whatever what happens to it.
There are multiple lessons that can be drawn from this long road. First of all, formal approaches are a great way to rethink known solutions. Why, because they are a tool helping the mind to think in a more abstract way. Known solutions are what prevent progress as they define how people look at things. It also helps to think out of the box questioning established practices. Of course, formal techniques are hard to use (certainly in the beginning) and there is the scalability limit. The way to overcome that is to move to the meta-levels, abstracting away the details. Formalisation is the key. To illustrate this with a small example, in the RTOS a priority-sorted linked list is used everywhere to implement waiting semantics. The first TLA+ models (influenced by the existing source code) also modeled the linked list. The result was that the model checker would not handle the state space explosion. One needs a lot of memory for that. Then it dawned on us that for the semantics of the services, the priority didn't matter and we just replaced it with a boolean. Simple but Smart. A complex solution is often a probem not well understood. But making it simple can take a serious effort even if with hindsight it was trivial. With formalisation and meta-modeling, it easier to think about the core and not the details and solutions are found.
There are many people who were involved in this roadmap. It were great times working with them as a team. I never programmed anything, even the C-language was never mastered. This was an advantage because it helped to think about behaviour, not about the implementation. VirtuosoNext and its visual application builder lives on under an Open technology License model The interested reader can browse www.altreonic.com and the internet for papers and presentations.
Eric Verhulst, 16th March 2026

Short presentation on Rosetta, Virtuoso in bed with Newton and Gödel. What's in an assumption?

Meanwhile, we rediscovered Rosetta at ESA's open door event in September 2025 at ESTEC.

Altreonic has now released a new version of the VirtuosoNext Designer (and RTOS) for Windows. This is a 64bit version and replaces the older OpenComRTOS Win32 version that is no longer fully functional on older Windows platforms. Together with a fully updated API manual, it can be downloaded and installed from the msi file on a Windows PC. Visit the download section.

Contact us for the external toolchain, available from our ftp server

Latest port of VirtuosoNext: Xilinx Zynq-7000 SoC variants with multi-core ARM A9 and M7 microcontrollers

The older OpenComRTOS hereby is deprecated and should no longer be used.

Hubs for VirtuosoNext: Online Verification of Real-Time Coordinators

The paper is a collaborative effort of: Guillermina Cledoua (a), José Proença (b), Bernhard H.C. Sputh (c), Eric Verhulst (c)

(a)HASLab/INESC TEC, Universidade do Minho, Portugal, (b)CISTER, ISEP, Portugal, (c)Altreonic NV, Belgium

Extended version at Zenodo.org
Esevier paper at https://www.sciencedirect.com/

Abstract

VirtuosoNextTM is a distributed real-time operating system (RTOS) fea- turing a generic programming model dubbed Interacting Entities. This pa- per focuses on these interactions, implemented as so-called Hubs. Hubs act as synchronisation and communication mechanisms between the application tasks and implement the services provided by the kernel. While the kernel provides the most basic services, each carefully designed, tested and opti- mised, tasks are limited to this handful of basic hubs, leaving the development of more complex mechanisms up to application specific implementations.

This work presents a toolset that supports the building of new services compositionally, using notions borrowed from the Reo coordination language, on which the developer can delegate coordination-related duties. This toolset uses a formal compositional semantics for hubs that captures dataflow and time, formalising the behaviour of existing hubs, and allowing the defini- tion of new ones. Furthermore, it enables the analysis and verification of hubs under our automata interpretation, including time-sensitive behaviour via the Uppaal model checker, usable on http://arcatools.org/hubs. We illustrate the proposed tools and methods by verifying key properties on different interaction scenarios between tasks and a composed hub.

My presentation was very well received. Of course, the ultimate question was that while ARRL-7 implies an independent supervisory organisation for automotive, the question is how this goal can be reached. Will the sector welcome it and accept the openness it needs (like in the aviation sector)? Nevertheless, I am convinced that it will be needed anyway. The move towards MaaS (vs. a market of vehicles) and safety concerns with ADAS and autonomous driving require it. In general, many presentations were about autonomous driving and especially the use of A.I. (read Machine Learning with Neural Nets). Personally I have doubts. Is this the right tool? And is this even the right problem to solve? These systems now use 1 TFlop (with no redundancy) and clearly the sensors are not yet a match for our eyes.  Maybe 100 TFlop and much  better sensors can give us Level 5. But is it then still worth it? 

https://www.linkedin.com/feed/update/urn:li:activity:6547831979230978050

Separation of concerns for resilient embedded real-time

Abstract:

Many embedded applications, specifically safety-critical ones, have strict real-time constraints. In the very worst case, missing a deadline can be catastrophic. Therefore, many approaches have been developed and successfully deployed whereby time is explicitly used to schedule the application tasks. A very important design paramater is a guaranteed Worst Case Execution Time (WCET). While this approach can be justified partly for historical reasons but also for reasons of simplicity, modern many-core processors pose a significant challenge as the chips combine multiple tightly coupled processing cores, fast caches to alleviate slow memory and complex peripherals. All these elements result in a statistical execution behaviour whereby a measure like WCET is no longer practical. In this paper we advocate that this situation requires a different approach to programming, i.e. one based on events and concurrency with time no longer being a strict design parameter but rather a consequence of the program execution. It is a consequence of applying a separation of concerns to execution in space and time. Benchmarks obtained with the latest version of VirtuosoNext Designer, a fine-grain partitioning multi-core RTOS, illustrate that this is not only feasible but also with no compromise on the real-time behavior. In the latest implementation this was extended to real-time fault recovery making systems much more resilient than with the traditional approach.

Eric Verhulst, CEO/CTO of Altreonic Kurt.mobi is invited speaker at:

Quality, safety and security for automotive software-based systems

In June 2019 the ninth VDA Automotive SYS Conference hosted by the Association of the German Automotive Industry will take place in Potsdam, Germany. Top-rated keynote speakers, experts and managers from E/E Development and leading service providers are going to share experience and knowledge.

Up to date with the changes in the development of embedded systems in the connected vehicle, the conference focuses on Quality, Safety and Security of modern vehicle electronics. The conference will deal both with technical methods/solutions and management practices with respect to the national and international automotive standards.

Title:

“Towards ARRL-7: safer vehicles for resilient Mobility as a Service”.

Abstract:

Autonomous systems have in the last years forced us to rethink the very notion of safety engineering. Exploring the complete state space be it for formal verification or for extensive testing has become elusive, leaving us with guesswork to estimate the residual error rate. Of course, we just know it is never zero. How to tackle this problem? We start by acknowledging some conceptual weaknesses of the safety standards. Safety standards consider safety engineering as a specific project and domain activity, each with its own SIL levels, which is not only costly but also questionable. Starting from the objective to promote reuse, we define a complementary criterion called ARRL (Assured Reliability and Resilience Level). Rather than starting from the system’s functions, it starts from the system’s architecture in relationship to resilience.  It promotes the notion of resilience to failures as a way to achieve a higher degree of safety and puts Quality of Service first.  Resilience also help to design with less complexity easing the burden of verification and validation. The higher ARRL levels also acknowledge that the system design is never finished and that the loop must be closed at a higher level.

More details at: https://vda-qmc.de/en/software-processes/vda-automotive-sys/

Altreonic Kurt.mobi and Tomen Energy in Shenzhen signed an MOU for a Joint Venture to further develop the market of its game changing battery technology. Based on a patented novel type of carbon based super capacitor, it will make electric vehicles become more like traditional ICE vehicles with fast charging and operating without any problems from -40°C, resp. -20°C to +50°C. No complex Battery Management System and no active cooling is needed. The battery itself remains very cool due to its very low internal resistance and thermal run-away risks are a thing of the past.  The batteries have a very long life time (20000 cycles and more) so that no costly midlife replacements are needed.  Overall, the novel batteries are a significant step for a practical transition to a clean and sustainable electricity driven world.