One recurring debate (in both consultancy practice and in academia) centres around whether Java is an appropriate language to use in safety-related applications. Anecdotally, there seems to be equal effort expended from the ‘nay camp’ that wouldn’t permit Java in a safety-related application in any form; and from those who devote time arguing for its acceptable use.
So what do Open Standards have to say on this contentious issue? Here I take a brief look at what the 3 ‘big hitters’ in safety-standard terms have to say (IEC/BS EN 61508, DO 178C, and ISO 26262).
Part 7 of BS EN 61508 [1] in its recommendations for specific programming languages notes that Java is ‘not recommended’ for use in any safety function (at any integrity), but that the use of Java ‘with subset’ is recommended for use in safety functions that attract an integrity no higher than SIL 2.
In the accompanying text in Table C.1 of the standard, it notes that a subset will include either no garbage collection, or should garbage collection be used, it should not cause the application code to stop for a “significant length of time”. Unfortunately, but unsurprisingly, it offers no insight in how much time is considered ‘significant’.
In terms of safer bets for safety-related applications, one can freely choose from stalwarts such as ADA, ADA with subset (highly recommended for safety functions that attract even a SIL of 4), PASCAL (equal to ADA when using PASCAL with a subset), FORTRAN 77 (with subset), C with a subset, C++ with subset and appropriate coding standard…and even Ladder Diagrams with a defined subset of language.
The unfavoured languages in 61508’s terms comprise the likes of C (only up to SIL 2) and Assemblers. Many will note the lack of consideration of languages such as Python, Ruby (on or off the rails!), Swift, and html etc. The reason for this? 61508 hasn’t been updated since the release of Issue 2 in 2010…and owing to the length of time it takes international stakeholders to agree on the finer points of standard-writing, the standard more-likely represents the latest thoughts of 2-years prior to its release (so from around 2009).
That we have extant safety standards that represent the latest research as of some 15 years prior is a cause for concern, and one must wonder what else needs to be changed from ‘current’ good practice espoused in such Open Standards…but that is an altogether different subject to be tackled in future blogs.
So…back to Java and 61508. What is a subset? Why is it seemingly ‘safer’ when used? What is garbage collection, and why should we care from a safety perspective?
DISCLAIMER: I am a safety scientist, not a software engineer – so this is my simplistic take from a system safety perspective (I remain happy to be corrected in the comments section).
A programming language (safe) subset [2] is a subset of the language that is defined specifically to have the properties that satisfy the requirements more adequately than the full programme. This makes perfect sense (from a 61508 requirements point of view), so all we need is this defined subset of Java. Henties et al noted that this was indeed almost here…in 2009 [3]…as they awaited the imminent arrival of a new standard that would “ facilitate the creation of safety-critical Java applications capable of certification under standards such as DO 178B level A or IEC61508 for SIL 4”. JSR 302 was “nearing completion” and would soon be available for public review. As quick as a flash, it was released for said review in May of this year (2021).
I have no idea what defined Java subsets have been used to date (can anyone help, here?), and without undertaking a systematic review, can only assume that Java hasn’t been used in any safety related applications (as no formalised subset yet exists). Unless, or course, specific arguments over a bespoke subset created for a particular instantiation have been made. Now before the comments section is filled with links to the plethora of academic papers, white papers, and grey literature out there…my point is there is no ‘recognised’ (standardised) subset I can find.
Garbage collection is the removal of superfluous information from computer memory [4] (that is no longer valid or wanted – normally associated with memory compaction). So why do we care about NOT having this from a safety perspective? Memory management is clearly a key attribute for safety, but the crux of the matter here is its drain on resources, and hence processing time (cf 61508’s requirement to only allow the use of garbage collection if it doesn’t stop the application code from running “for a significant length of time”.
Another ‘popular’ standard would be DO-178C [5]. This RTCA document has a section on programming language and compiler considerations that only really notes the verification considerations of both when choosing a programming language. Instead, 178C relies on the use of coding standards to define the programming languages, methods, rules, and tools to be used to code the software. It permits the use of programming languages with or without subsets (although does note that limiting the use of some features of a language may be required) and merely gives examples of what such a standard SHOULD include.
A check of the ‘Bingo Tables’ in Annex A merely notes that the (loose) objectives for coding standards should me met for all DALs. This lack of guidance isn’t surprising from an ARP-suite document, however – as they rely on the regulating and/or certifying body to agree such intricate details with the developer
Part 6 of ISO 26262 [6] suggests that design and coding guidelines for programming languages can be considered (but from a source external to the ISO!). When selecting a language, it suggests the following criteria:
- An unambiguous definition
- Support for embedded real time software and runtime error handling
- Support for modularity, abstraction and structured contents
Although a stalwart and advocate of ‘C’ (and why not with all the MISRA guidance out there!), 26262 lists ‘Java’ as an example of a potential programming language and merely notes that programming/modelling languages CAN be used to ‘comply’ (although I am not sure how one complies with suggestions!). It does provide a table of what it refers to as ‘topics’ to be covered by any coding guidelines which is paraphrased as:
- Enforcement of low complexity
- Use language subsets
- Enforcement of strong typing
- Use defensive programming
- Use established design principles
- Use unambiguous graphical representation
- Use style guides
- Use naming conventions.
There exists a plethora (ever-growing) of programming languages out there, but rather than taking an exhaustive (exhausting) comparison of the many languages and their perceived benefits and drawbacks, let us examine instead what we DO want from a programming language for it to be used in a safety-related application.
A non-scientific review of the three big hitters suggests that we can infer that we require a programming language that (either in isolation or use with a coding standard/guidelines):
- Is used with a subset (or some specific limitation so unused aspects are not included)
- Does not use garbage collection
- Will support modularisation, abstraction, and structures contents
- Be verifiable and testable
- Enforces low complexity
- Utilises defensive programming techniques
- Uses style guides
- Uses naming conventions
- Facilitates static verification of conformance to the specified design.
Arguments must also be made over the following subjective attributes (terms emboldened and presumably reliant on a coding standard):
- Follow recognised good practice for programming
- Have ‘code understandability’
- Provide support for embedded real time software and runtime error handling
- Uses established design principles.
Owing to the guidance of 61508 – and until more recent research is published, we should limit these attributes to only considering safety functions that attract a SIL no higher than 2, and the language should be capable of achieving them ALL.
The question one must ask therefore, is whether effort should be expended on arguing over the suitability of Java in safety-related applications…or choose another programming language.
The answer will differ with every project – of that I have no doubt.
References
[1] Bs, “BSI Standards Publication Functional safety of electrical / electronic / programmable electronic safety related systems Part 7 : Overview of techniques and measures,” 2010.
[2] S. Neil, Safety-Critical Computer Systems. Harlow: Addison-Wesley, 1996.
[3] T. Henties, J. J. Hunt, D. Locke, K. Nilsen, M. Schoeberl, and Jan Vitek, “Java for Safety-Critical Applications.” 2009.
[4] A Dictionary of Computer Science, 7th Editio. Oxford: Oxford University Press, 2016.
[5] RTCA, “Software Considerations in Airborne Systems and Equipment Certification,” RTCA DO-178C, 2011.
[6] “BSI Standards Publication Road vehicles — Functional safety Part 6 : Product development at the software level.” BSi, 2011.