Is a Subset Acceptable?
An initial determination should be made to ensure that a subset is permissible before work starts on identifying the guidelines that are to be excluded from it. The first step is to understand certification requirements. If a project needs to be certified before it is put into service, then the requirements laid down by the certification body will be a primary driver. It is possible that a specific coding standard may be mandated, one must be chosen from a set of approved standards, or the choice may be left to contractual arrangements. The body may further restrict what subsetting is permitted or may prohibit it entirely, especially if compliance with an approved standard is formally verifiable. The process is slightly different when there is no requirement for certification prior to deployment. It is likely that many projects will be expected to adhere to an international industry-specific standard (e.g., ISO 26262 for automotive, IEC 62304 for medical systems), especially if those projects have high integrity requirements. Certification of compliance will either be via a certification authority or by means of selfcertification. These international standards generally require the use of a language subset defined by means of a coding standard. The project may have more flexibility to decide if it is appropriate to use a subset of a coding standard, especially when the safety requirements are less stringent than when a certification body is involved. Additional key points include determining whether the chosen coding standard permits a subset to be used and whether the supply contract allows the use of a subset (Figure 2).
Subset Selection Criteria
Once it has been shown that a coding standard subset is acceptable for the project, selection of candidate guidelines can proceed. Choosing the subset depends on the type of issue covered by the standard. The guidelines offered by a standard generally fall into one or more of the following areas, with a particular standard providing guidance in one or more of them: â€˘ Language issues (e.g., prevention of undefined behavior) â€˘ Security issues (e.g., buffer overrun errors that enable the execution of malicious code)
Leading Safety-Critical Standards Avionics
DO-178B (First published 1992) / DO-178C
IEC 61508 (First published 1998) Railway
CENELEC EN 50128 (First published 2001)
IEC 61513 (First published 2001)
ISO 26262 (First published 2011)
IEC 62304 (First published 2006)
IEC 61511 (First published 2003)
Figure 2 Many safety-critical standards have evolved from the generic standard IEC 61508. Sectors that are relative newcomers to this field (highlighted) are advantaged by the availability of established and proven tools to help them to achieve their goals.
Figure 3 Building secure code by eliminating known weaknesses.
â€˘ Stylistic matters (e.g., use of tabs versus spaces) These areas present different criteria to consider when selecting guidelines to eliminate from a subset: Implementation-defined language behavior: Languages such as C include behavior that varies between implementations. The implementer is required to document how any such implementation-defined behavior is actually implemented so that a user may account for it when writing code. Coding standard guidelines are often designed to flag the
effects of such behavior because it may be different from that which a coder is expecting based on previous experience with another implementation. This is a pragmatic approach as it ensures that any implementation-defined behavior that might affect the project is identified. Use of such behavior is often unavoidable, however, especially with C. It may therefore be appropriate to exclude one or more related guidelines from a standard subset, provided that adequate measures are put in place (e.g., staff training) to ensure this does not compromise the design. RTC MAGAZINE DECEMBER 2012