Auto recalls and software quality in the automotive sector

Software for automobiles is one from innovative factors in the automotive industry. Automobile is represented as an amount of embedded systems (embedded systems) and it is a very complex computing system. It is currently estimated that the average car has built-in software in the range of 100 million lines and in 2020 is already expected 300 million lines of code. The contribution is devoted to the management of safety and reliability of the software development for embedded systems designed for electromechanical (mechatronic) systems through quality assurance of embedded software. The contribution defines the term software quality assurance strategy, explains the role of standards such as ISO 26262 (Road vehicles - Functional safety), ISO 15504 (Automotive SPICE 3.0)


Introduction
Today's vehicles have evolved from a mechanical device into an integrated machine with embedded software powering grater performance in all major systems. These technological improvements are driving brand success stories, and consumer's experiences are shaped as much by the software and hardware. Now more than ever, software quality needs to be at the top of the list for major auto brands looking to preserve -and elevate -brand status. Controls and information systems require in a modern car 100 million lines of code that is more than a Boeing 787 (6.5 million lines). When a smartphone's software fails or a desktop computer's operating system crashes, it can cause a major inconvenience. But it pales in comparison to a vehicle software failure that could affect braking, acceleration or any number of functions while we're barreling down the highway at 100 km/h. That's why vulnerabilities in software-connected components -from internal malfunction to external hacking -have been the subject of increased attention by manufacturers, regulators and the public.

Auto recalls
An auto recall occurs when a manufacturer (or the National Highway Traffic Safety Administration (NHTSA) in the USA or another regulators) determines that a car model (or several models) has a safety-related defect or does not comply with a federal safety standard. When this happens, the automaker will alert owners to the problem and usually offer a free repair. Keep in mind that a recall doesn't mean that the entire vehicle will be replaced. NHTSA recorded 51 million vehicle recalls in 2015, slightly more than the 2014 total, which was adjusted downward from about 64 million to just under 51 million due to double-counting that occurred in 2014 related to the Takata recall [1]. Through various announcements, the Takata recall has tripled in size over the past year. It is expected that the inflator recall will impact more than 42 million vehicles in the U.S., with the total number of airbags being between 65 and 70 million. Some key statistics about the 2015 recalls [2]: .  The largest non-Takata recall of 2015 was issued by Toyota, related to a power window electrical switch that could short-circuit and potentially catch fire. It affected more than 1.8 million units. The Figure 1 shows overall recall trends and unique campaigns and units affected by decade Last year's most publicized story about an automobile defect was when the Environmental Protection Agency (EPA) cited Volkswagen for bypassing the emissions control system in almost 500,000 vehicles sold in the U.S. (and many more globally) [3]. The EPA issued a notice of violation to the automaker, letting it know that the vehicles were discharging more pollutants than legally acceptable [4]. Indications are that this could be the most expensive recall ever, topping out at $14.7 billion USD [5]. The completion of this recall will likely be much more challenging than a typical safety recall. Once Volkswagen figures out how to fix the issue in accordance with EPA standards, it will then need to entice people to return to dealerships for the repair. However, owners might resist the fix, particularly if it will have a negative effect on performance and gas mileage. As a result, VW will need strong incentives and proactive outreach to bring people into dealerships.  [13]. Recalls of software-related components have dramatically increased in the last few years. Since the end of 2012, there has been a marked increase in recall activity due to software issues. For the primary light vehicle makes and models we studied, 32 unique software-related recalls affected about 3.6 million vehicles from 2005 -2012. However, in a much shorter time period from the end of 2012 to June 2015, there were 63 software-related recalls affecting 6.4 million more vehicles. From less than 5 percent of all recalls in 2011, software related recalls have risen to almost 15 percent in 2015. Overall, the amount of unique campaigns involving software has climbed dramatically, with nine times as many in 2015 than in 2011, as both Figure 2 and Figure 3 indicate. Over the years, more and more components rely on an automobile's internal computers instead of traditional analog systems. Such components include fuel mixture management, automatic braking, air bag sensors, and seats that detect the driver's weight and position. All have the potential to fail. Auto recalls and software quality in the automotive sector 3 including forward collision avoidance and automatic brake controls. According to the Insurance Institute for Highway Safety (IIHS), autonomous collision avoidance technology is being offered by as many as 22 OEMs as of January 2016. In 2015, three new software-related categories reported data for the first time [2]:

Software recalls and technical service bulletins
 Automatic Braking, listed on 21 EWR reports, resulting in 26 injuries and 1 fatality  Electronic Stability, listed on 6 EWR reports, resulting in 7 injuries and 1 fatality  Forward Collision Avoidance, listed in 1 EWR report, resulting in 1 injury and no fatalities In addition to software recalls, researchers discovered an increase in software related Technical Service Bulletins (TSB), which identify issues with specific components, yet stop short of a recall. TSBs are issued when manufacturers provide recommended procedures to dealerships' service departments for fixing problematic components (120 unique TSBs in 2014 and 2015 years).

Systems development life cycle (SDLC) and V -model
The systems development life cycle (SDLC), also referred to as the application development life-cycle, is a term used in systems engineering, information systems and software engineering to describe a process for planning, creating, testing, and deploying an information system. The systems development lifecycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. The V-model is a graphical representation of a systems development lifecycle. It is used to produce rigorous development lifecycle models and project management models. The V-model falls into three broad categories, the German Das V-Modell, a general testing model and the US government standard. The V-model summarizes the main steps to be taken in conjunction with the corresponding deliverables within computerized system validation framework, or project life cycle development. It describes the activities to be performed and the results that have to be produced during product development. The left side of the "V" represents the decomposition of requirements, and creation of system specifications. The right side of the V represents integration of parts and their validation .However, Requirements need to be validated first against the higher level requirements or user needs. Furthermore, there is also something as validation of system models (e.g. FEM). This can partially be done at the left side also. To claim that validation only occurs at the right side may not be correct. The easiest way is to say that verification is always against the requirements (technical terms) and validation always against the real world or the user needs.

Systems and software engineering: ISO/IEC 12207
The ISO/IEC 12207 Systems and software engineering -Software life cycle processes is an international standard for software lifecycle processes [14]. It aims to be the standard that defines all the tasks required for developing and maintaining software. The ISO/IEC 12207 standard establishes a process of lifecycle for software, including processes and activities applied during the acquisition and configuration of the services of the system. Each Process has a set of outcomes associated with it. There are 23 Processes, 95 Activities, 325 Tasks and 224 Outcomes (the new "ISO/IEC 12207:2008 Systems and software engineering -Software life cycle processes" defines 43 system and software processes).The standard has the main objective of supplying a common structure so that the buyers, suppliers, developers, maintainers, operators, managers and technicians involved with the software development use a common language. This common language is established in the form of well-defined processes. The structure of the standard was intended to be conceived in a flexible, modular way so as to be adaptable to the necessities of whoever uses it. The standard is based on two basic principles: modularity and responsibility. Modularity means processes with minimum coupling and maximum cohesion. Responsibility means to establish a responsibility for each process, facilitating the application of the standard in projects where many people can be legally involved. The set of processes, activities and tasks can be adapted according to the software project. These processes are classified in three types: basic, for support and organizational. The support and organizational processes must exist independently of the organization and the project being executed. The basic processes are instantiated according to the situation. (model) to assess the capability and maturity of organizational processes to develop software resp. embedded systems in the automotive industry. It is a variant of ISO 15504 tailored to the needs of the automotive industry. The framework is used by automotive OEMs and suppliers to assess the capability and maturity of their development processes for software and embedded systems. The process reference part of the model defines the central processes relevant to be inspected and to be performed in any software/embedded system development. The process assessment part of the model describes how to evaluate the capability of processes within the organization.

Automotive
A maturity model is an organizational comparison tool designed to evaluate an organizations methods and processes against industry best practices; and based upon the results, provide a maturity rating (which is effectively a process and capability rating), enabling organizations to determine supplier suitability. Since 2005 when the Automotive SPICE model was published, many car manufactures have adopted ASPICE to evaluate both software and electronics suppliers. Key to the success of ASPICE is the scope of the model, accounting for domain specific models within an overall umbrella model. As we show later ASPICE maturity model is a requirement base for embedded software automotive suppliers according to the upcoming manufacturing quality management system in the automotive industry according to the IATF 16949.

Software engineering -Product quality: ISO/IEC 9126 and ISO/IEC 25010:2011
ISO/IEC 9126 Software engineering -Product quality was an international standard for the evaluation of software quality. It has been replaced by ISO/IEC 25010:2011. The fundamental objective of the ISO/IEC 9126 standard is to address some of the well-known human biases that can adversely affect the delivery and perception of a software development project. These biases include changing priorities after the start of a project or not having any clear definitions of "success". By clarifying, then agreeing on the project priorities and subsequently converting abstract priorities (compliance) to measurable values (output data can be validated against schema X with zero intervention), ISO/IEC 9126 tries to develop a common understanding of the project's objectives and goals. The standard is divided into four parts: quality model, external metrics, internal metrics and quality in use metrics. The quality model presented in the first part of the standard, ISO/IEC 9126-1 classifies software quality in a structured set of characteristics and sub-characteristics as follows:  Functionality -"A set of attributes that bear on the existence of a set of functions and their specified properties.

Functional safety -road vehicles: ISO 26262 and IEC 61508
Functional safety features form an integral part of each automotive product development phase, ranging from the specification, to design, implementation, integration, verification, validation, and production release. The standard ISO 26262 is an adaptation of the Functional Safety standard IEC 61508 for Automotive Electric/Electronic Systems. ISO 26262 defines functional safety for automotive equipment applicable throughout the lifecycle of all automotive electronic and electrical safetyrelated systems. The first edition, published on 11 November 2011, is intended to be applied to electrical and/or electronic systems installed in "series production passenger cars" with a maximum gross weight of 3500 kg. Draft of new edition of this standard was published at end 2016. It aims to address possible hazards caused by the malfunctioning behaviour of electronic and electrical systems. Although entitled "Road vehicles -Functional safety" the standard relates to the functional safety of Electrical and Electronic systems, not to that of systems as a whole or of their mechanical subsystems. Like its parent standard, IEC 61508, ISO 26262 is a risk-based safety standard, where the risk of hazardous operational situations is qualitatively assessed and safety measures are defined to avoid or control systematic failures and to detect or control random hardware failures, or mitigate their effects. Goals of ISO 26262:  Provides an automotive safety lifecycle (management, development, production, EAI Endorsed Transactions on Scalable Information Systems 04 2018 -05 2018 | Volume 5 | Issue 17 | e3 5 operation, service, decommissioning) and supports tailoring the necessary activities during these lifecycle phases.  Covers functional safety aspects of the entire development process (including such activities as requirements specification, design, implementation, integration, verification, validation, and configuration).  Provides an automotive-specific risk-based approach for determining risk classes (Automotive Safety Integrity Levels, ASILs).  Uses ASILs for specifying the item's necessary safety requirements for achieving an acceptable residual risk.  Provides requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety is being achieved. ISO 26262 is an extension of IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems. IEC 61508 defines Safety Integrity Levels (SILs). ISO 26262 defines ASILs. It might seem that ASILs are like SILs and that anyone familiar with building a safety case for a system requiring certification to an IEC 61508 SIL should be able to transfer those methods to an ISO 26262 project. .ASIL's are three dimensional, involving three variables: severity, probability of exposure, and controllability. ISO 26262-3, section 7 "Hazard analysis and risk assessment" provides tables that break these three variables down into classes. Probability of exposure has five classes: "Incredible" to "High probability" (E0-E4). Severity has four classes: "No injuries" to "Life-threatening injuries (survival uncertain), fatal injuries" (S0-S3). Controllability, which means controllability by the driver, not by the vehicle electronic systems, has four classes: "Controllable in general" to "Difficult to control or uncontrollable." [15] 4.6 Manufacturing quality management system in the automotive industry: ISO/TS 16949 and IATF 16949 The ISO/TS16949 is an ISO technical specification aimed at the development of a quality management system that provides for continual improvement, emphasizing defect prevention and the reduction of variation and waste in the automotive industry supply chain. It is based on the ISO 9001 standard and the first edition was published in June 1999 as ISO/TS 16949:1999. It was prepared by the International Automotive Task Force (IATF) and the "Technical Committee" of ISO. It harmonizes the countryspecific regulations of quality Management systems. About 30 percent of the more than 100 existing automobile manufacturers affiliate the requirements of the norm but especially the large Asian manufacturers have differentiated, own requirements for the quality management systems of their corporate group and their suppliers. TS16949 applies to the design/development, production and, when relevant, installation and servicing of automotive related products. The requirements are intended to be applied throughout the supply chain. For the first time vehicle assembly plants will be encouraged to seek ISO/TS16949 certification.
On October 3rd, 2016 IATF 16949:2016 was published by the IATF and supersedes and replaces the current ISO/TS 16949, defining the requirements of a quality management system for organizations in the automotive industry. Deadline for transition from ISO/TS 16949 becomes IATF 16949 is 14 September 2018. In addition to ISO 9001:2015, besides another requirements the new requirements is expected for products with embedded software. This new clause adds requirements for organization-responsible embedded software development and software development capability self-assessments. Organizations must use a process for quality assurance of products with internally developed embedded software, and have an appropriate assessment methodology to assess their software development process. The software development process must also be included within the scope of the internal audit program; the internal auditor should be able to understand and assess the effectiveness of the software development assessment methodology chosen by the organization like in previous text mentioned Automotive SPICE.

Conclusions
As resume of this contribution we should emphasis next ideas:  Today's automotive software is very complex and huge (100 million lines of code Auto recalls and software quality in the automotive sector automotive software should performed its software developing processes with conformance with automaker required software developing process capability level (according to the Automotive SPICE, standard ISO/IEC 33001). Internal and external assessors are performing estimation process capability level for each automotive components with embedded software.