Products

Shifting Demands Don't Need to be Automatic Vulnerabilities

By borsem

This year may very well go down as a bellwether in the history of automotive engineering, as the year when software truly became recognized as the most discussed and notable components in vehicle manufacturing. During the ongoing revolution in power and power trains, the relentless digitization of most every vehicle subsystem, now at the dawn of autonomous self-driving vehicles, software was certainly already at the forefront of automotive engineering. The amount of software code inside modern automotive products is breathtaking, dwarfing the code-bases found in most any other engineering endeavor. What has made this current year distinguishing are the several high-visibility revelations which have served to vividly demonstrate, to manufacturer and consumer alike, just how dependent vehicles have become upon their software, and just how vulnerable vehicles have become because of their software.


Software and the New Age of Recalls


IMG_20150901_094026The year of 2014 shattered previous automotive industry records as the year of the most recalls in history –by various estimates well over 500 recall campaigns involving some 50-60 million units. To be sure, there have been software caused recalls already, many times over, going back a decade at minimum. Although specific attribution to software within the available recall data are often imprecise (and therefore quite possibly understated), software defects have been identified as being responsible for countless recall efforts, many of which were at least as high-profile when they occurred, as are today’s recent issues which are receiving considerable media attention. The importance of software, the opportunities made possible by software, the challenges of developing software, and the implications of software defects or poor quality, are well understood by automakers and throughout the industry. The present-day recalls of millions of vehicles for software patches to address hacking exposures appear to have even further heightened awareness, and have sensitized the entire global market. Our modern era of instantaneous communication may definitely play a part as a contributing factor, yielding not only immediate reporting of vehicle issues (almost daily), but also in terms of the ubiquitous sharing of information, including even ‘car hacking handbooks’ which can be readily obtained over the Internet (ostensibly factions within the cybersecurity and automotive tech communities believe that openness in automotive software can achieve similar defect identification benefits that open-source movements have attained in other domains).

Process and Quality: More Critical Than Ever


What has unquestionably come into sharper focus as a result of all these many recent events is the vital criticality of automotive software development processes, and the imperative of automotive software developers to be able to produce high-quality deliverables. In particular this climate emphasizes the crucial importance of quality assurance processes within the software development lifecycle, the absolutely fundamental need for comprehensive traceability across all development phases and areas, as well as compliance with an ever-growing set of functional safety considerations pertaining to software development. Where software development teams are exploiting application lifecycle management (ALM) practices already, their ability to up-their-game with respect to evolving their process capabilities is decisively enhanced.

Standards Must Evolve – and Soon


Functional safety has been a primary consideration in manufacturing for a considerable time, and has resulted in an automotive-specific standard in ISO 26262 articulating detailed guidance concerning functional safety risk management, and risk mitigation during the production of software for E/E/PE systems and equipment. Arguably the many recent news headlines may provide evidence that ISO 26262 may not be as well understood by automakers as it should be, and/or that the standard as it exists presently does not adequately contemplate the increased importance and inherent vulnerability of software, nor an advancement of software capabilities in several crucial areas –notably advanced driver assistance systems (ADAS), connected vehicle communications, and inter-vehicular communication systems. Certainly as technology evolves, so too must quality assurance processes, as well as relevant safety standards, and it is therefore reasonable to assume that standards such as ISO 26262 will undergo requisite revision over time. Seemingly, the vitality of the risk assessment framework provided by the standard remains sound. The incorporation and integration of functional safety standards, risk assessment and mitigation, and process capability assessment, to make them more ingrained within the software development lifecycle, must undergo reconsideration and improvement.

Focus on Lifecycle Integration and Software Quality


Tighter integration between the so-called safety lifecycle inherent in the ISO / IEC standards with the software development lifecycle is, now more than ever, increasingly essential.Too often however, stringent functional safety requirements, when combined with increasing software content and complexity, are considered more of a headache and an overall product development burden to be endured, rather than an integral element and overarching consideration permeating all development phases. The now energized market will force greater emphasis upon software’s safety integrity, and will demand higher software quality overall much more keenly and rapidly than the traditional liability, litigation, and regulatory mechanisms prevalent in the automotive sector during previous decades. Even non-safety critical systems will be subject to amplified quality expectations, which will be equally challenging to software development processes as these systems are no less complex (often more so), and frequently interact directly with consumers in ways that are beyond just the driving experience. The art and science of automotive software development must be prepared to respond –as a matter of life and death for not only drivers and passengers, but also most assuredly for brands and corporations.

Assessments of software development process capabilities, and the relative maturities of such processes, will also undoubtedly assume more prominent importance in the automotive domain, not only with regard to regulatory and compliance purposes, but also with respect to quality management, and in broader terms for the control of financial liability and monetary reserves for potential liabilities, for purposes of corporate governance, and even for financial statement disclosures.

Process assessment and improvement includes a far more extensive set of considerations, as processes and sub-processes are intrinsic throughout all activity intending to achieve any goal, and exist irrespective of the underlying engineering disciplines. Further, metrics to quantify process capability and maturity may encompass quality attributes and customer satisfaction levels. Generalized process assessment and capability measurement frameworks, such as CMMI, therefore have applicability in the automotive domain, for numerous activities including industrial processes, supply-chain interaction and management, and obviously also software development.

Standards, ALM and SPICE


Alternatively, an evolving set of standards (ISO/IEC 12207, ISO/IEC 15504, ISO/IEC 33xxx) have been promulgated over time for processes specific to software acquisition, development, and engineering, much of which provide the genesis regarding conventional understanding and acceptance of application lifecycle management (ALM). The later iterations of such standards have focused upon topics pertaining to Software Process Improvement and Capability Determination (SPICE), which have applicability in virtually any domain involving software development activity. Further refinements of the SPICE precepts and principles within these ISO/IEC standards, towards a more specific relevance for automobile manufacturing, have given rise to the Automotive SPICE Process Assessment and Reference Models which, although based upon the underlying standards, are promulgated by a regionalized industry consortium effort.

No matter which path is chosen in a process improvement journey, all capability assessment frameworks are predicated upon common elements pertaining to documentation, management of change, traceability, auditability, and reporting, and furthermore process-level assessment intersects with functional safety considerations as they may relate directly to process capabilities regarding risk management. Documentation and reporting are keynote attributes. Software development is an innately complex and dynamic environment, and producing comprehensive documentation and maintaining its currency is not trivial. Ability to provide self-documenting and collaborative capabilities within and across processes are pivotal to a maturity which does not impinge upon agility and innovation. And as standards setting entities typically do not provide certification or conformity assessment, organizational capability to perform objective self-assessment, and/or to fulfill external audit requirements with respect to approval evidence and activity conformance reporting, are therefore mission critical.

A Proven Platform


Polarion Software recognized early on the significance of ALM with respect to safety-critical applications, with emphasis on embedded software development, and especially for software development within highly regulated, and/or standards driven industries. Polarion has responded to the needs of automotive systems engineers and software development teams to incorporate ISO 26262 risk assessment and classification early in their software development lifecycles, and to ensure functional safety compliance and traceability during verification and validation phases.

Polarion products have attained independent certification as a trusted toolset in accordance with ISO 26262 and IEC 61508, freeing customers of the labor to qualify their development environment. With many tools and technology partners, Polarion’s unifying solution provides a vibrant ecosystem serving the multi-faceted needs of the automotive domain.Polarion remains committed to providing software engineers in the automotive sector with the ALM environment they will need to respond to a new era of software innovation and reliability, and to succeed in a climate of rapidly evolving sets of standards, regulations, and best practices.

Find out more about how Polarion Software’s successes and solutions for the Automotive industry by visiting our Automotive Solutions page.



webinar banner

Borse Michael

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at https://blogs.stage.sw.siemens.com/polarion/shifting-demands-dont-need-to-be-automatic-vulnerabilities/