Software quality initiatives in automotive system development
February 01, 2014
Software checking and monitoring tools add another degree of safety when automotive systems hit the road.
The automotive sector has for many years been on a quality-improvement mission. Driven by the proliferation of software applications residing in the average car, and the enormous growth in the size, volume, interaction, and interoperability of these pieces of software, the challenge has been to place all this development in a controlled and robust environment. OEMs and suppliers need to ensure they have better visibility and control over the quality of all of the software and increasingly rely on the use of tools and coding standards to help give quality assurance to their customers and avoid the risk of costly recalls and delays in development.
Software quality in the automotive sector
Today the automotive industry has the twin standards initiatives of the ISO 26262 functional safety standard and Motor Industry Software Reliability Association’s C coding standards (MISRA-C – read more about MISRA) that jointly represent a solid basis for setting software quality goals in the automotive sector.
Ratified in November 2011, ISO 26262, which is an adaptation of IEC 61508, addresses functional safety in automotive passenger car production, and has been widely adopted by the whole automotive industry. It mandates the use of strong defensive coding standards such as MISRA C.
The MISRA C coding rules, which can be deployed either as a subset or in their entirety, have already become the de facto standard since their introduction in 1998 and recent second revision in 2012. MISRA C is used within organizations’ development groups and between suppliers, contractors, and customers to ensure code quality and compliance.
The new revision of MISRA C primarily supports the use of the C99 standard of the C language as well as C90 with the additional benefits that brings for software developers who can now take advantage of C99’s enhanced features in data handling in their products. By adding C99 support the standard has been updated with new rules, improved explanations and definitions to ensure correct containment of the C language and compliance to the standard.
Software quality testing perspectives
Different stakeholder groups often have a different perspective and approach to software quality. However, in an increasingly diverse software ecosystem it is a necessity to share a common basis for measuring quality.
For senior managers in automotive companies, quality is heavily influenced by regulatory demands and fiduciary responsibility, and monitoring quality has become as important as cost and schedule. What is needed at this level is an overall picture of software quality, a common and consistent measurement standard, and a trend line for current and past projects with particular focus on upcoming release milestones.
Software engineering groups need a more detailed and in-depth quality focus, but crucially one that matches this top-line measurement.
For project leads and managers, the detailed state of compliance to the applicable standard and overall quality goals must be readily available, broken down by developer and project.
For developers, quality tooling must integrate right into their software development environment and produce precise quality advice relating to the latest code changes.
The quality assurance group has often had to rely on external lag metrics like testing failures and bug data collection. What they really need is a quality system focused on true leading measures such as detailed coding compliance, code complexity measures, and other inherent software quality artifacts.
There are a number of common pitfalls when deploying a quality system solution:
· A solution that works for a developer on isolated code might not adequately scale up to entire projects and throughout the organization
· Analysis must yield near-zero false positives; all diagnostic output must reflect real addressable conditions
· Likewise, no area of quality conformance should be ignored or missed; every coding rule must be addressed with meaningful diagnostics
· Real-world limitations in the achievement of full compliance must be recognized; sophisticated and controlled deviation from rule adherence is needed
· Visibility at higher organization levels must match the detailed low-level compliance efforts; any disconnect between stakeholders will lead to disenfranchisement
Automotive software improvements
The automotive sector has seen dynamic growth in software use over the past decade, and recently the industry is seeing some profound trends in the area of quality attainment and focus.
While analysis tools like QA·C have historically been applied in a Validation & Verification mode once the code has been written, in recent years there has been a strong drive for more upfront use by developers as they write the actual code – a clear manifestation of prevention being better than cure. This is firstly coming from customers demanding that suppliers demonstrate upfront compliance to industry best practices. And, secondly from the diverse and distributed contributors to predominantly software-based components who want to reduce the disruptive rework impact of non-compliant code.
An interesting extension to the principle of deviation to full compliance is underway in the Japanese automotive marketplace. The industry is coming together to organize a very tightly controlled set of deviation cases from full MISRA compliance. Each case where a deviation is to pertain must be agreed and its rationale, safety case, and other background information stated upfront. Only the set of agreed deviations would be permitted to apply across the Japanese automotive industry, which marks an extension in sophistication in coding compliance. Therefore, companies supplying to the global market would need to be able to validate their code base for individual market conditions.
Automated tool solutions
Static analysis, the key ingredient for achieving code quality, is an integral part of the development environment. Extending it across the enterprise requires an approach that recognizes different levels of user engagement. In QA·Verify, PRQA has developed a tool that harnesses the analysis output of static analysis tools like QA·C and QA·C++ into a set of views to reach a wider audience.
The following are facilities needed in a good quality management reporting system:
· Review of diagnostic output, provided to an audience outside of the development environment, is a strict necessity
· Exploring underlying non-compliances and code bugs promotes greater collaboration between stakeholders
· A key capability is the presentation of trend charts of project-level metrics covering compliance, complexity and other suitable measures yielding cross-project comparisons and pre-release warning signals
· Advanced collaboration features can include annotation of coding decisions and common understanding between all appropriate stakeholders, and a deep-rooted code inspection environment backed up by sophisticated exposure of source code details
When embraced this holistic approach to testing using automated tools promotes a higher level of productivity, code quality and code reuse, which in turn will lead to faster time to market for new projects and reductions in over-runs and rework.
Automating tools for automotive systems
The automotive sector is enjoying a period of rapid growth and sophistication in software applications. There is recognition of the need to match functional enhancements with quality initiatives, and to ripple this philosophy out through the supplier chain. Recognizing the pitfalls in deployment of such a system, the answer is to be found in sophisticated and capable automated tooling solutions that deliver quality analytics to all stakeholders.