SAE PT-161-2013 Software-Hardware Integration in Automotive Product Development (To Purchase Call 1-800-854-7179 USA Canada or 303-397-7956 Worldwide).pdf

《SAE PT-161-2013 Software-Hardware Integration in Automotive Product Development (To Purchase Call 1-800-854-7179 USA Canada or 303-397-7956 Worldwide).pdf》由会员分享，可在线阅读，更多相关《SAE PT-161-2013 Software-Hardware Integration in Automotive Product Development (To Purchase Call 1-800-854-7179 USA Canada or 303-397-7956 Worldwide).pdf（121页珍藏版）》请在麦多课文档分享上搜索。

1、Software-Hardware Integration in Automotive Product Development PT-161_Front_matter.indd 1 10/9/13 9:40 AMOther SAE books of interest: Multiplexed Networks for Embedded Systems By Dominique Paret (Product Code: R-385) Automotive Software Engineering By Joerg Schaeuffele and Thomas Zurawka (Product C

2、ode: R-361) Vehicle Multiplex Communication By Christopher A. Lupini (Product Code: R-340) For more information or to order a book, contact: SAE International 400 Commonwealth Drive Warrendale, PA 15096-0001 USA Phone: +1.877.606.7323 (U.S. and Canada only) or +1.724.776.4970 (outside U.S. and Canad

3、a) Fax: +1.724-.776.0790; Email: CustomerServicesae.org; Website: books.sae.org PT-161_Front_matter.indd 2 10/9/13 9:40 AMSoftware-Hardware Integration in Automotive Product Development Edited by John Blyler Warrendale, Pennsylvania, USA PT-161_Front_matter.indd 3 10/9/13 9:40 AM Copyright 2014 SAE

4、International. eISBN: 978-0-7680-8078-0Copyright 2014 SAE International. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, distributed, or transmitted, in any form or by any means without the prior written permission of SAE International. For permissio

5、n and licensing requests, contact SAE Permissions, 400 Commonwealth Drive, Warrendale, PA 15096-0001 USA; e-mail: copyrightsae.org; phone: 724-772-4028; fax: 724-772-9765. ISBN 978-0-7680-8052-0 Library of Congress Catalog Number 2013949773 SAE Order Number PT-161 DOI 10.4271/ PT-161 Information con

6、tained in this work has been obtained by SAE International from sources believed to be reliable. However, neither SAE International nor its authors guarantee the accuracy or completeness of any information published herein and neither SAE International nor its authors shall be responsible for any er

7、rors, omissions, or damages arising out of use of this information. This work is published with the understanding that SAE International and its authors are supplying information, but are not attempting to render engineering or other professional services. If such services are required, the assistan

8、ce of an appropriate professional should be sought. To purchase bulk quantities, please contact SAE Customer Service e-mail: CustomerServicesae.org phone: +1.877.606.7323 (inside USA and Canada) +1.724.776.4970 (outside USA) fax: +1.724.776.0790 Visit the SAE International Bookstore at books.sae.org

9、 400 Commonwealth Drive Warrendale, PA 15096-0001 USA E-mail: CustomerServicesae.org Phone: 877-606-7323 (inside USA and Canada)724-776-4970 (outside USA) Fax: 724-776-0790 PT-161_Front_matter.indd 4 10/9/13 9:40 AMv Table of Contents Introduction 1 Papers 13 Adaptation of a “Virtual Prototype” for

10、Systems and Verification Engineering Development (2008-21-0043) Chandrashekar, M. S., Manjunath, B. C., Lumpkin, E. R., and Winters, F. J. 13 Verification and Validation According to IEC 61508: A Workflow to Facilitate the Development of High-Integrity Applications (2009-01-2929) Conrad, M., Friedma

11、n, J., and Sandmann, G. 23 Hardware/Software Design and Development Process (2006-01-0170) Lumpkin, E., and Gabrick, M. 29 Using VHDL-AMS as a Unifying Technology for HW/SW Co-verification of Embedded Mechatronic Systems (2004-01-0718) Egel, T. R., and Elias, N. J. 41 Virtual Prototypes as Part of t

12、he Design Flow of Highly Complex ECUs (2005-01-1342) Krech, J., Mayer, A., and Raab, G. 51 To Test the Need and the Need to TestTesting the Smart Controller Network for the Chassis of Tomorrow (2008-21-0041) Deiss, H., Krimmel, H., and Maschmann, O. 59 A Systems Engineering Approach to Verification

13、of Distributed Body Control Applications Development (2010-01-2328) Yang, J., Bauman, J., and Beydoun, A. 67 Highly Scalable and Cost Effective Hardware/Software Architecture for Car Entertainment and/or Infotainment Systems (2004-21-0071) Troemel Jr., H. A., and Burk, M. 79 Analysis of Interfaces a

14、nd Interface Management of Automobile Systems (2008-01-0279) Fritzsche, R. 91 Advancements in Hardware-in-the-Loop Technology in Support of Complex Integration Testing of Embedded System Software (2011-01-0443) Himmler, A., Waeltermann, P ., and Khoee-Fard, M. 99 About the Editor 113 PT-161_Front_ma

15、tter.indd 5 10/9/13 9:40 AMPT-161_Front_matter.indd 6 10/9/13 9:40 AM1 1.0 Introduction All of the papers referenced in this compendium attest to the difficulties of the integration, verification, and validation (IVV) phase of the automotive hardware and software system life cycle. Yet, the future o

16、f automotive product development lies in the timely integration of these chiefly electronic and mechanical systems. How can the automotive industry overcome these difficulties? These carefully selected papers demonstrate how leading companies, universities, and organizations have developed methodolo

17、gies, tools, and technologies to integrate, verify, and validate hardware and software systems. The integration activities cross both product type and engineering discipline boundaries to include chip-, embedded board-, and network/vehicle-level systems. Integration, verification, and validation of

18、each of these three domains will be examined separately and then together. Each of the domains uses identical terms to describe key concepts, elements, and processes (e.g., modeling, hardware-software, and systems). Before proceeding, these terms and others must be defined to avoid confusion, and se

19、t the proper context for the rest of the book. IVV is that portion of the complete product or system life-cycle phase captured in the right-hand side (RHS) of the V-diagram model (see Fig. 1). This RHS portion is sometimes called the “build, test, and deliver phase 1.” The models left-hand side is w

20、here the architectural design is functionally partitioned and decomposed into manageable subsystems and components. At the lowest levels of decompositioni.e., the bottom of the “V”the resulting subsystems are ready to be recomposed into an integrated whole. This integration phase is where verificati

21、on, validation, and test of all the hardware and software occur. Fig. 1 Model-based V-diagram showing areas of focus (SAE Paper 2008-21-0043). PT-161_Front_matter.indd 1 10/9/13 9:40 AM2 What is meant by verification and validation? How does testing fit into all these activities? Verification is the

22、 process of ensuring that the system or product was built correctly, as specified by the design. Similarly, validation ensures that the correct system or product was built (i.e., that the correct problem was addressed). Verification and validation are accomplished by testing at every level, from ind

23、ividual subsystems/units through the integration of the complete system. The current state of the art is to integrate, verify, validate, and test automotive hardware and software with a complement of physical hardware and virtual software prototyping tools. The growth of sophisticated software tools

24、, sometimes combined with hardware- in-the-loop devices, has allowed the automotive industry to meet shrinking time-to- market, decreasing costs, and increasing safety demands. It is also why most of the papers in this book focus on virtual systems, prototypes, and models to emulate and simulate bot

25、h hardware and software. Further, such tools and techniques are the way that hardware and software systems can be “co-verified” and tested in a concurrent fashion. Are physical hardware and software prototyping tools the best way to perform IVV and test? Probably not, according to Bill Chown, produc

26、t marketing director for the system- level engineering division at Mentor Graphics. “It is very hard to do worse case or statistical analysis with a specific instance or even limited set of instances of a piece of hardware,” observed Chown. What can be done? A model-driven design, implementation, an

27、d test approach has gained growing acceptance over the years 2, 3. A model-driven development (MDD) process supports verification of the model at each stage of design and thus reduces reliance on late-stage physical integration and testing as the primary means to validate the system, notes Chown. An

28、other benefit of model-driven development is its supports of the design and verification of mechatronic automotive systems and the growing need for cross- disciplinary collaboration. Mechatronics is a development process that requires a combination of mechanical, electrical/electronic, control, and

29、computer engineering disciplines. “Vehicle electronics and embedded systems currently represent 20 to 40% of global development costs and are projected to grow at 9% a year,” noted Michael Lalande, Director of Transportation & Mobility, Dassault Systmes. “To control development costs and remain comp

30、etitive requires the integration of mechanical, electronic, and software components into one virtual and collaborative environment.” But a virtual environment requires extensive modeling of all hardware and software components and processes. However, once created, these virtual models can be used ag

31、ain and again. The reuse of mechanical and electronic hardware as well as software code, libraries, and models is a critical element of todays design and integration activities. Reuse of such intellectual property (IP) is a prerequisite to meet performance, time, and cost demands of modern hardware-

32、software systems. PT-161_Front_matter.indd 2 10/9/13 9:40 AM3 The goal of this compilation of expert articles is to reveal the similarities and differences between the integration, verification, and validation (IVV) of hardware and software at the chip, board, and network levels. This comparative st

33、udy will reveal the common IVV thread among the different, but ultimately related, implementations of hardware and software systems. In so doing, it supports the larger systems engineering approach for the vertically integrated automobilenamely, that of model-driven development. 2.0 Embedded Board-L

34、evel Hardware-Software In the past, the greatest obstacle in hardware-software development was one of time- dependence. Software could not be started until the hardware platform on which the software ran was finished. Today, faster and less expensive computational platforms and model-based methodolo

35、gies ensure that software can be designed and verified in sync with the hardware (i.e., co-designed and co-verified). Such co-development approaches require the use of simulation models and virtual prototypes. Software designers have long appreciated the benefits of virtual prototypes, which ran at

36、increasing speeds and complexity thanks to the increasing computational benefits of Moores law. These same performance benefits are now enjoyed by hardware designers and integrators. (See Paper 2008-21-0043, “Adaptation of a Virtual Prototype for Systems and Verification Engineering Development.”) S

37、tandards have also helped the verification and validation (V&V) effort. First, they provide a set of specifications for moving between levels of abstraction (e.g., untimed architectural design through detailed, timing-specific hardware models). Secondly, at a process level, standards provide a commo

38、n way for V&V to be handled. An example of the latter is ISO 26262, an international functional safety standard. It is an adaptation of the IEC 61508 specification for electrical and electronic systems in the road vehicle industry. While focused on the development of in-vehicle application software

39、development, work is being done to implement this approach with model-based developments. (See Paper 2009-01-2929, “Verification and Validation According to IEC 61508: A Workflow to Facilitate the Development of High-Integrity Applications.”) Interestingly, the success of ISO 26262 might serve as a

40、working model for V&V in other industries such as chip design and electronic design automation (EDA) tools. The implementation of hardware-software systems is significantly different in each of the three major domains or abstraction-levels (i.e., chip-, embedded board-, and the network/vehicle-level

41、). For example, system-on-chip (SoC) developers understand hardware in terms of transistor-based devices, and verification is increasingly handled as part of a bundled IP reuse package. These IP packages are typically the hardware cores and software stacks needed for popular interface input/output (

42、I/O) subsystems such as standard PCIe bus or Ethernet interface. Additionally, such IP subsystems include both the hardware and software and the verification and integration suites need to ensure that the interface (e.g., Ethernet) PT-161_Front_matter.indd 3 10/9/13 9:40 AM4 is properly integrated a

43、nd tested within the larger system, such as the rest of the automobile electronics 4. At the next level of abstraction beyond the chip are embedded board-level developers who view hardware in terms of microprocessor/microcontroller components, specialized chips, memory, and interface subsystems. Sof

44、tware is seen in terms of firmware or device drivers, and a hardware-centric real-time operating system (RTOS) that may be part of a high-level operating system (OS). Finally, boards are connected into larger network-based systems that include the entire vehicle. In automotive terms, multiple embedd

45、ed control units (ECUs)consisting of the previously mentioned componentsare distributed across one or more of the SAE International automotive network classifications such as Local Interconnect Network (LIN), Controller Area Network (CAN), Media Oriented Systems Transport (MOST), FlexRay, and Ethern

46、et 5. Here, board-level embedded hardware systems become a subsystem to modules and larger network systems. Board-level firmware and operating systems (OSs) become secondary to network operating systems (NOS), middleware, and finally end-user applications. Naturally, there could be an even higher le

47、vel above networks that connect the automobile to other transportation systems. But in the context of a single automobile, hardware and software integration occurs at these three levels. Most automotive experts agree that a vertically integrated system for designing and verifying all hardware and so

48、ftware subsystems is vital for todays safety- critical, consumer- driven automotive market. 3.0 Chip-Level Hardware-Software The essence of hardware and software co-design/co-verification is parallelization (i.e., enabling both design and verification to proceed at roughly the same time early in the design process and continuing through verification, testing, and final product integration). Achieving this goal requires the use of virtual systems to investigate trade- off options between hardwaresuch as microprocessors, memory, and interfacesand softw