Model Based Testing Applied to In-house Embedded Software Development
چکیده
The use of electronics in automobiles has increased over time. Today, the vehicle is a complex network of systems made by electronic control units, with different purpose. To manage this complex Software Systems Engineering task, Fiat Group Automobiles (FGA) formed a Software Factory Team within the Electronics Architecture Group. The team goal is to design, develop and test Software Component Module following AUTOSAR consortium guidelines. To manage all phases, SPICE standard level 2 is implemented. The team is formed by software engineers, which design CCODE and test engineers which develop test cases. There are two principal activities of testing: design, execute test case and analyze the results. If the results are negative, deviation must be reported and followed up. All activities are Model Based Design centered: this allows to predict general behaviour of the system, accelerate design cycle, reuse of test cases and it permits greater flexibility. This tecnique also helps to guarantee a good interaction between software design and software integration, in order to find out errors and bugs due to the interaction between software components. INTRODUCTION The amount of software in vehicles grows exponentially and this increase brings various challenges: key competencies, processes, methods, tools, models, division of work, maintenance, and long term strategies. Today premium cars include about 70 ECUs and up to 5 different communication buses. Up to 40 percent of the production costs of a car are due to electronics and software [1]. For hybrids, where the amount of software needed for engine control is greater than others, the cost of electronics, as a percent of vehicle costs, is closer to 45 percent. Within 10 years, some experts predict that the percentages relating to the cost of electronics are expected to rise to 50 percent for conventional vehicles and 80 percent for hybrids [2]. Also, safety requirements, high emissions reduction mandated by government regulations and an increase of comfort in a car will probably lead to an enhancement in terms of electronics contents. In this scenario carmakers are forced to re-defined all the lifecycle production code, from the definition of the requirements to the verification and integration in a ECU: Fiat Group Automobiles (FGA in the following) decides to change thinking and basic idea of software design following AUTOSAR AUTOmotive Open System ARchitecture -standard that improves complexity management of integrated E/E architectures through increased reuse and exchangeability of SW modules. Software Factory team is part of Electronic Architectures in FGA E&D department and it aims to design, develop and test Software Component Module (SWC in the following) observing AUTOSAR standard. In the article, there is a short description of general state of art in software production. Then an explanation of testing strategy in FGA Software Factory is given. Finally a list of current FGA projects which uses this technology is showed. BACKGROUND Traditionally the car industry is vertically organized. In software engineering it is very different, more modular. The mechanical engineering made the various sub-systems in cars quite independent. As a result, suppliers could take over a considerable part of the engineering, the development, and also the production by a consequent outsourcing. Ideally, the parts of cars were produced by a chain of suppliers and more or less only assembled by the car manufacturer (called OEM Model Based Testing Applied to In-house Embedded Software Development 2010-01-2326 Published 10/19/2010 Maria Cavallaro and Antonio Marino Fiat Group Automobiles S.p.A. Copyright © 2010 SAE International in the following). This could lead to outsourcing of a large amount of the engineering and production that optimized the cost and risk distribution. A car was considered as a kit of subparts that were assembled by the OEM [1]. With software, as a new innovating force driving, the situation has been changed radically. The car changes from an assembled device into an integrated system and unintentional feature interaction become issues. The costs of cars start to depend more and more by costs of software development. The behavior of cars becomes much more programmable: some properties, such as comfort or sportive handling are no longer determined only by the mechanics but also by the software/electronics. This situation has led to systems with a huge size and lots of embedded software/hardware structure in cars. In current premium cars more than ten million lines of code are present and this number will probably increase in the next generation.This implies new competencies, especially in the development processes. In fact it is very important to be able to increase, as fast as possible, expertise in the software engineering domain in an Organization. All the processes are influenced by software engineering and this will be more and more common. As a result the complexity and spectrum of requirements for on board software is enormous [1]. An example is the new innovative electro-hydraulic system integrated in the FGA engines called Multiair. Processes and models of software engineering have influenced a lot of mechanical engineering design: the whole mechanical valve control is driven by a software/electronic strategy AEC Adaptive Electronic Control. FUTURE DOMAIN The future development is driven by the following trends: • new innovative or improved functionality • quickly interchanging platforms and system infrastructures • rapid increase in development cost • request of higher quality and reliability • shorter time-to-market In this context AUTOSAR consortium plays a fundamental role. AN OVERVIEW ABOUT AUTOSAR The AUTomotive Open System ARchitecture (AUTOSAR) was founded as a development partnership in 2003. The growing complexity of software and electronics makes integration increasingly difficult, with negative impact on reliability. AUTOSAR consortium makes true a common objective between OEMs and Tier 1 suppliers: to create a basis for industry collaboration providing a platform which continues to encourage competition on innovative functions (see Fig. 1). In particular: • Implementation and standardization of basic system functions as an OEM wide “Standard Core” solution • Scalability to different vehicle and platform variants • Transferability of functions in the network • Integration of functional modules from multiple suppliers • Consideration of availability and safety requirements • Maintainability throughout the whole “Product Life Cycle” • Software updates and upgrades over vehicle lifetime • Confirmation of legal aspects (environmental aspects and safety requirements). • Enforcement in comfort and entertainment functional domains needs • Driver assistance and dynamic drive aspects that include detection and suppression of critical dynamic vehicle states and navigation in high density traffic surroundings Figure 1. The concepts around AUTOSAR All these aspects can be summarize in three main groups: • Architecture Integration of all platforms for hardware independent software application • Methodology To achieve seamless configuration, seamless description formats and templates. Also to share standard process life cycle for software stack and integration of application software level in ECUs. • Application interfaces Definition of interfaces related to automotive application in order to create a standard for software application level. The AUTOSAR standard will serve as a common platform where vehicle applications will be implemented and will also serve to minimize the current barriers between functional domains. It aims to enable mapping of functions and functional networks to different control nodes in the system, almost independently from the associated hardware (see Fig. 2). Software organization is formed by: • Basic Software, that contains modules such as the operating system services and communication, • RTE layer, abstracts the SWC layer from any implementation details of the basic software and is responsible for SWC communication, • Application layer contains the application function code organized in atomic independent SWCs. This permits to develop them independently of each others [3] [4]. In the application layer there are SWCs which implement standard or specific core function of every OEMs (see Fig. 3). AUTOSAR concept supports Model Based Design technique that allows significant advantages in terms of better cost design and a significant reduction of development Figure 2. Before and after the introduction of AUTOSAR Figure 3. Software organization in AUTOSAR time.Model-Based Design (MBD shortened) is a software development technique which uses models that can be simulated. In MBD a designer models functionalities, and tests them on a PC with real-time simulation. The real-time simulation enables to verify and validate the algorithm, by using codes generated from the model. Furthermore, auto code generation products enables to generate C/C++ program for embedded controller (microprocessor, DSP, etc.). With Model-Based Design, engineers improve efficiency for the following reasons: • Hardware prototype reduction and fail-safe verification by real-time simulation • Efficient test by model verification • Using a common design environment across among project teams • Linking designs directly to requirements • Integrating testing with design to continuously identify and correct errors • Automatically generating embedded software code with coding time and error reduction • Developing and reusing test suites • Automatically generating documentation • Achieving best time to market In recent years model based design methodology has become the preferred method for designing, modeling and simulating complex dynamic systems [5] [6]. SPICE In order to develop software component modules, Software Factory team has defined and implemented a process to manage all phases of work. This process has been implemented based on the reference process model called SPICE and it references to international standard ISO/IEC 15504. SPICE (Software Process Improvement and Capability dEtermination) aims to evaluate organization process in order to measure the capability and the improvement attitude of its internal processes. Processes are evaluated in terms of organization, technique and quality [7]. For each of them, ISO/IEC 15504 defines a capability level (see Fig. 4) on the following scale: Level Name • 5 Optimizing process • 4 Predictable process • 3 Established process