Over weeks I ask my self why so many ISO certified software is always talking about C/C++ and extensions made to specific frameworks like ROS(2).
Let us first look at something what almost ever stated in this context: real-time. Due to ROS2 documentation “Real-time software guarantees correct computation at the correct time“, from stimulus to response in a specific time, where most pattern have “workarounds for blocking calls in the OS“, because, blocking for an indeterminate amount of time is nondeterministic. Further the ROS2 documentation states that the written code is to break down into three parts:
- a non real-time safe section: preallocates memory on the heap because it can run into page faults, while loading memory from disk to RAM, and will at least block I/O operations, starts threads, etc.
- a real-time safe section which is often implemented as a loop, because locking can result in deadlocks, miss aligned priorities and,
- a non-real-time safe “teardown” section that deallocates memory as necessary, etc.
When I compare it with discussions I had years before regarding Javascript and the Google V8 Javascript engine, it well covers the needs. The V8 engine is single threaded to achieve asynchronous behaviour. The heart of this single thread is the so called event-loop, as stated before “is often implemented as a loop“. The event loop itself is realized by a library called “libuv“. The “libuv” library offers asynchronous execution while the user code still runs on a single thread. Everything which should happen asynchronously is offloaded and calls back when the result is available e.g., like file I/O. Often this feature is called “non blocking I/O“, because the main task are not blocked by I/O.
Some might call the V8 engine approach an “event driven architecture“, because the event loop orchestrates a bunch of expensive worker threads out of a given worker pool. The term expensive covers
- I/O when the OS don’t offer a non-blocking version of communication with things outside a process as well as,
- CPU-intensive operations performed by the process.
The worker pool and the event loop are decoupled via queue’s using a mechanism like epoll (Linux), kqueue (OSX), event ports (Solaris), or IOCP (Windows). The passed events are messages (aka tasks). Each task is pre-empted; it is atomically executed and calls back afterwards. This implies that the event loop might
- not execute (b)locking code and
- don’t require execution prioritization.
But does this imply realtime or even safety? No, not mandatory. It is a step in the right direction. It avoids failure which might happen and being addressed in ISO26262 audits. V8 well supports “reliability” as described by ISO 8402 – the capability of a system to respond in a proper timeframe.
But realtime and safety often share the concern of memory operations and exception handling. Why? Some call it type safety (no sorry it is not about a type system for variables), but at the end it is about having pre-allocated memory which not get fragmented, miss used, etc. With V8 a garbage collector (- the name is “Orinoco”-) take control. The developer is not responsible for managing memory, what implicitly prevent wild pointer and potential memory leaks, etc. The memory
- for the call stack
- for the variables (the heap) as well as
- exception handling
gets managed. Furthermore the V8 engine does not do an Javascript interpretation, it produces machine code. The internal compiler, doing the job, is called “TurboFan”. Due to that all compiled code passes a abstract syntax representation (AST) and gets semantically validated before it becomes machine code:
Is it now safety related? No, again jet another step in the right direction. Tooling and reproducibility is an important value for safety certification, as with ISO26262 – may call it “state of art” software development technology.
What is “state of the art” for software development? Let us have a quick mind storming:
- Requirement elicitation with clear traceability to code
- FMEA analysis, with failure cause, failure effect, failure impact, failure measure, resulting in a safety concept
- Design & architecture documentation e.g., such as ARC42
- Verification & validation (from requirements to code & code back to requirements) of produced software including static code analysis, unit-test,- integration-test, system-test, performance-test and fault-injection-test
- Safety manual of how to configure everything
Something else? What defines ISO26262 for us? Generally a bunch of criteria:
- S = Severity of damage (low to high)
- E = Probability of driving situation exposure (low to high)
- C = Controllability of driving situation (good to bad)
resulting in a so called ASIL classification:
Overall it is about deciding on a probability. How probable is an event, causing safety risks. A really nice paper can be found here (external link, German).
Coming back to our root question. NodeJS is a central software component, acting as a runtime for further software components. This implies all code running in the V8 runtime can only be so “good” classified as the runtime itself.
To answer the initial question, we have consider it as a safety element out of context (SEooC). It is a candidate to be integrated into a safety relevant item – e.g., a vehicle.
Due to ISO26262 clause 6.4.5.6(simplified):
If the safety activities are tailored based on a „reasonable and credible“ safety plan because an element is developed separately from an item, then the development of this element shall be based on a requirement specification that is derived from assumptions on an intended use and context, including its external interfaces; and the validity of the assumptions on the intended use and context of the element developed separately established during item integration.
Can NodeJS be ISO26262 ASIL D certified? I would say yes, it can.
Your feedback is highly welcome 🙂