D2.1.4 Development Method Restricted (PP) Copyright DESERVE. Development Method. Sub Project SP2 ADAS development platform

Transcription

1 Development Method Deliverable n. D2.1.4 Development method (final release) Sub Project SP2 ADAS development platform Workpackage WP2.1 Tools and development systems Tasks T2.1.1 T2.1.2 T2.1.3 T2.1.4 T2.1.5 Analysis of existing tools and methods Development system Tools selection and adaptation Development method Selection and implementation of an analytical modelling approach for system on chip concepts Authors A. Rolfsmeier et al. dspace GmbH File name Status Distribution D21.4 Development method (Final release).docx Final Restricted (PP) Issue date 05/10/2014 Creation date 11/07/2014 Project start and duration 1 st of September, months

2 REVISION AND HISTORY CHART Ver DATE AUTHOR REASON A. Rolfsmeier (dspace) Draft version of the document prepared for final release A. Rolfsmeier (dspace) Revision of the contents A. Rolfsmeier (dspace) Minor corrections F. Giesemann, N. Mentzer, G. Payá Vayá, H. Blume (IMS) Final release of Chapter A. Rolfsmeier (dspace) Contribution by AVL integrated in chapter A. Rolfsmeier (dspace) Peer review feedback from ICOOR integrated A. Rolfsmeier (dspace) Final version

3 TABLE OF CONTENTS REVISION AND HISTORY CHART... 2 TABLE OF CONTENTS... 3 LIST OF FIGURES... 4 LIST OF ABBREVIATIONS... 5 EXECUTIVE SUMMARY INTRODUCTION Objective and scope of this document Structure of the deliverable ANALYSIS OF EXISTING TOOLS AND METHODS DEVELOPMENT SYSTEM TOOLS SELECTION AND ADAPTATION DESERVE platform based on EB Assist ADTF and FPGA board DESERVE platform based on RTMaps and MicroAutoBox II Extended interface options to the DESERVE platform Sensor Interfaces to the Embedded Controller Interface options to the FPGA board Concept for a modular x86 based development platform Parameter optimization approach for application algorithms SELECTION AND IMPLEMENTATION OF AN ANALYTICAL MODELLING APPROACH FOR SYSTEM ON CHIP CONCEPTS Design Space Exploration Case Studies DEVELOPMENT METHOD CONCLUSIONS REFERENCES Page 3

4 LIST OF FIGURES FIGURE 1 - MODEL-BASED DESIGN AND RAPID PROTOTYPING OF APPLICATION FUNCTIONS 11 FIGURE 2 - ESTABLISHED RAPID PROTOTYPING TOOL-CHAIN FOR ADAS DEVELOPMENT 12 FIGURE 3 EXTERNAL BYPASS APPROACH WITH RAPID PROTOTYPING 13 FIGURE 4 DESERVE PLATFORM CONCEPT FOR DEVELOPING ADAS ALGORITHMS 15 FIGURE 5 DESERVE PLATFORM CONCEPT FOR REAL-TIME IN-VEHICLE USE CASES 16 FIGURE 6 PROTOTYPE OF DESERVE DEVELOPMENT SYSTEM 16 FIGURE 7 DESERVE PLATFORM AND DSE FRAMEWORK 18 FIGURE 8 - DESERVE PLATFORM ARCHITECTURE ON CRF PASSENGER CAR 19 FIGURE 9 - DESERVE PLATFORM ARCHITECTURE ON CRF HIGH END CAR 20 FIGURE 10 INTERFACE OPTIONS WITH FPGA BOARD OF DESERVE PLATFORM 21 FIGURE 11 - CONCEPT OF A MODULAR X86 PROCESSSOR BASED DEVELOPMENT PLATFORM 22 FIGURE 12 TOOL CHAIN FOR AUTOMATED CALIBRATION USING AN ECU ON AN ENGINE TEST BED AS AN EXAMPLE 23 FIGURE 13 TOOL CHAIN FOR AUTOMATED CALIBRATION OF ADAS APPLICATION ALGORITHMS 24 FIGURE 14 - DESIGN SPACE EXPLORATION FRAMEWORK IN THE DESIGN FLOW FOR HETEROGENEOUS HARDWARE ARCHITECTURES 25 FIGURE 15 - OBJECTIVES IN THE DESIGN SPACE 27 FIGURE 16: NORMALIZED WORK AMOUNT OF THE HOG COMPUTATION OVER SCALING FACTOR S ON THE INTEL XEON PHI MIC AND THE INTEL XEON GPP 28 FIGURE 17: RESULTING HARDWARE ARCHITECTURE OF AN ADABOOST STAGE RESULTING FROM A SOFTWARE PARAMETER SET EXTRACTION 29 FIGURE 18: COST MODELS DERIVED FROM SYNTHESIS RESULTS FOR A SUPPORT VECTOR MACHINE, IMPLEMENTED ON A FPGA. THE ARCHITECTURAL PARAMETERS CUT_MX AND CUT_ML DESCRIBE THE LIMITING OF INTERNAL REGISTER WIDTH 30 FIGURE 19 - ADAS DEVELOPMENT PROCESS USING THE DESERVE PLATFORM Page 4

5 LIST OF ABBREVIATIONS ABBREVIATION DESCRIPTION ADAS Advanced Driver Assistance Systems ADC Analog-to-Digital-Converter AEB Automatic Emergency Braking ASIC Application Specific Integrated Circuit CAN Controller Area Network CFAR Constant False Alarm Rate Dx.y.z DESERVE deliverable x.y.z DAC Digital-to-Analog-Converter DoE Design of Experiments DSE Design Space Exploration DSP Digital Signal Processor FPGA Field-Programmable Gate Array ECU Electronic Control Unit ehorizon Electronic Horizon Gbit/s Gigabit/s (1000 Mbit/s) HW Hardware ITS-G5 Intelligent Transportation System Generation 5, in Europe referred to as IEEE p Page 5

6 IWI Intervention Warning Information I/O Inputs/Outputs LCV Light Commercial Vehicle µc Microcontroller LRR Long-Range Radar MRR Medium-Range Radar OEM Original Equipment Manufacturer, i.e., the automobile manufacturer OS Operating System PC Personal Computer SoC System on Chip SPU Signal Processing Unit SW Software UDP User Datagram Protocol UUT Unit Under Test VHDL Very High Speed Integrated Circuit Hardware Description Language VRU Vulnerable Road Users V2X Vehicle to Vehicle, Vehicle to Infrastructure WPx.y DESERVE Work Package x.y XCP Universal Measurement and Calibration Protocol Page 6

7 3G/4G Third/fourth Generation of mobile phone communication technology standards, often associated with UMTS and LTE Page 7

8 EXECUTIVE SUMMARY In this deliverable D2.1.4 (under work package 2.1 with the title Tools and development systems ) the following items are addressed: the identification of suitable tools and development methods for the DESERVE platform, the evaluation of how these tools and methods have to be adapted to meet the DESERVE requirements, the description of the final release of a specific DESERVE prototyping platform, and the presentation of a methodology for ADAS algorithm development using the above mentioned DESERVE platform and an analytical modelling approach for system on chip. The complete prototyping tool-chain is heterogeneous and manifold, depending on the actual application scenario and development stage the DESERVE platform is used for. However, at least three different approaches are identified: fully PC-based development platform, mixed PC and embedded controller platform comprising an optional FPGA, and in-vehicle prototyping platform consisting of embedded PC, embedded controller, an optional FPGA and optional hardware accelerators. The platform concepts for selected DESERVE demonstrators are introduced. In particular, the architecture of one specific DESERVE prototyping framework and the associated methods related to different development stages are addressed. The big challenge during ADAS development is to close the gap between the individual development stages and to make the whole development process as seamless and integrated as possible. For this, guidelines are presented outlining how the development of ADAS perception and application algorithms can be facilitated by means of this specific prototyping framework. Simulation tools for vehicle dynamics, the traffic environment and for the execution of test scenarios are not in the scope of this deliverable Page 8

9 1. Introduction 1.1. Objective and scope of this document The objective of this deliverable is to derive the final version of the DESERVE development platform and to provide basic guidelines on how to use this platform for the development of advanced driver assistance systems. This document is based on the following DESERVE deliverables: D Development Platform Requirements, D Development Platform Specification, and D1.3.2 Method and Tools Specifications. The associated specifications are developed further concentrating on selected platform concepts which are used in DESERVE demonstrators. While D1.3.2 introduces development methods from a more general point of view, this deliverable focusses on specific tools associated with the DESERVE development platform and rapid prototyping. After the analysis of existing development approaches the associated platform concept is derived and specified. In particular, the architecture of the DESERVE prototyping platform and methodologies for ADAS algorithm development are addressed, referring to chapter 2 and 3 in D Simulation tools for vehicle dynamics, the traffic environment and for the execution of test scenarios are not in the scope of this deliverable. Details are given on how to use the associated hardware and software components with special focus on rapid prototyping of perception and application algorithms. In this regard a brief handbook or user guide is presented. Based on the findings described in this deliverable, a specific development platform in terms of a real hard- and software system has been implemented in D Structure of the deliverable The structure of this document reflects the different tasks associated with work package WP2.1. The results of each task are described in a dedicated chapter: Chapter 1 gives an overview of the objective and the structure of this document. Chapter 2 provides an analysis of available tools and relative development methods to understand at which level these methods already fulfil the DESERVE specification defined in the previous work packages. Chapter 3 outlines the concept of the DESERVE development platform. Chapter 4 describes how already available systems and tools have to be adapted to meet the requirements for the DESERVE platform and how the individual DESERVE demonstrators look like. Chapter 5 outlines the analytical modelling approach for system on chip to be implemented in the context of the DESERVE project. Chapter 6 proposes development methods and guidelines associated with a specific DESERVE prototyping platform. Chapter 7 briefly summarizes the main ideas presented in this deliverable Page 9

10 2. Analysis of existing tools and methods The DESERVE platform has to be based on state-of-the art tools which are typically used for the development of ADAS applications. To understand at which level these tools already fulfil the specifications defined in the previous work packages the associated development methods are analysed. As outlined in D1.3.2 the model-based design of ECU software with regard to application functions is well-established in the automotive industry. Typically, tools like MATLAB /Simulink [1] or ASCET [2] featuring a graphical programming language are used for the design of application software. These tools also support the automatic generation of C-code for different target platforms and some of them also of VHDL-code for FPGAs directly from the modelling environment. Applying model-based design, ECU application functions are typically developed by means of the rapid prototyping approach. This way new controller strategies can be implemented early in the development process in short iteration cycles and verified directly in the vehicle. Established tool-chains for rapid prototyping in the automotive industry are provided, for example, by the companies dspace [3] and ETAS [4]. Figure 1 illustrates the model-based design and rapid prototyping workflow. Especially the dspace AutoBox and MicroAutoBox platforms featuring a real-time operating system and a scalable, embedded controller and I/O based hardware architecture are widely used in research and development. The MicroAutoBox, a kind of prototyping ECU with a predefined set of I/O interfaces, is a robust and compact stand-alone system which is in terms of shock, vibration, temperature, and booting time qualified for in-vehicle use [5]. Compared to this, the AutoBox features a modular hardware architecture allowing the processing power and the I/O interfaces to be scaled according to the individual application via dedicated plug-in-boards. Typically rapid prototyping systems serve as a platform for the implementation of application and controller algorithms, respectively, by directly interfacing sensors, actuators and the vehicle bus. Compared to final production ECUs these systems usually provide more processing power and virtually unlimited RAM and flash resources, so even complex algorithms can be calculated in real-time Page 10

11 Figure 1 - Model-based design and rapid prototyping of application functions Due to the model-based design approach, application algorithms that have been developed in terms of Simulink models during the rapid prototyping phase, can easily be transferred to the final production ECU. This ECU typically features a single or multi-core microcontroller for processing the application algorithms. For this transfer, target code generators such as TargetLink [6] or the Embedded Coder [7] are used which allow ECU production code or even microcontroller specific code to be generated directly from Simulink. If developers adhere to certain modelling styleguides right from the beginning, exactly the same models can be used in the complete development process from prototyping to production code generation. The associated tools usually support AUTOSAR software components on the application level as well [8]. AUTOSAR is a standard for the ECU software architecture in the automotive area, and it provides means to facilitate the exchange and update of ECU software and hardware. This includes the standardization of ECU basic software such as system services and the microcontroller abstraction layer as well as interfaces for application software components. Thus, the AUTOSAR standard supports the scalability of software and its transfer to different vehicle and platform variants, the software integration from multiple suppliers, and the maintainability throughout the entire product life-cycle. However, AUTOSAR does not address the architecture of perception, fusion and tracking algorithms. These algorithms are typically developed on MS Windows or Linux PCs using dedicated software frameworks such as EB Assist ADTF [9] or RTMaps [10] which are described in D at great length. These tools allow various sensors and vehicle busses to be Page 11

12 interfaced and different kinds of algorithms to be implemented in terms of C/C++/C# code that is embedded in specific blocks, also called filters. However, using standard PCs with a Windows or Linux operating system does not always guarantee real-time behavior. In addition, modelling tools such as Simulink are not directly supported by these frameworks. Another Windows-based environment for developing perception, fusion and tracking algorithms is provided by the company BASELABS [11]. The associated development framework is very similar to EB Assist ADTF and RTMaps, however there is one important distinction. It features a library of basic modelling blocks, each of them representing an individual source code module, by means of which algorithms can be designed graphically. The code for the overall perception, fusion or tracking algorithm can then be generated automatically in terms of C++ and even C code for embedded platforms. An established tool-chain for prototyping ADAS functions is described in Figure 2. This tool-chain already provides interfaces to ADAS related sensors and actuators as well as a flexible hardware concept for the implementation of the perception and application platform as well as the IWI-Controller. In this regard, it already reflects the idea of the DESERVE platform framework described in figure 1 of D Figure 2 - Established rapid prototyping tool-chain for ADAS development Basically there are two approaches to rapid prototyping: fullpass and bypass. With fullpass, the prototyping system calculates the complete algorithms associated with a certain ECU or application. All sensors and actuators are connected to the prototyping framework, and it has full control of the associated system. With bypass, in particular the external bypass approach, the prototyping system is used in parallel to an existing ECU [12]. The synchronized connection between the two systems is implemented via dedicated bypass or ECU interfaces. Typically, only specific software functions that are Page 12

13 under development are offloaded from the ECU to the prototyping system as outlined in Figure 3. Figure 3 External Bypass approach with rapid prototyping In chapter 3.3 of the deliverable D2.5.1 dedicated bypass concepts for the development of ADAS functions utilizing client-server access methods are introduced. Client-server interfaces, for example, are typically used to call AUTOSAR service functions in the ECU. In contrast to the model-based design approach for application functions which supports a seamless software transition from the prototyping to production phase, a similar methodology for the development and target implementation of perception, fusion and tracking algorithms is not yet established and standardized in the automobile industry. Due to the associated complexity and the high amount of sensor data to be processed, the related algorithms for driver assistance systems are usually computationally very intensive and the implementation on the final embedded hardware requires real-time performance. Purely software-based solutions are often not appropriate. Thus, for the implementation of these algorithms on the target platform in the vehicle different system on chip (SoC) architectures have to be evaluated. For example, the SoC architecture may be based on an FPGA, a multi-core processor, DSP, an ASIC or combinations of them. Ideally, the final hardware architecture is identified early in the development process to avoid an algorithm redesign during the transition from prototyping to production [13]. The rapid evaluation of different implementation options according to given cost criteria, also called design space exploration, is required for this (see chapter 5 in D1.3.2) Page 13

14 3. Development system Based on the specifications outlined in the DESERVE work package WP1.3 and the previous analysis of existing tools and methodologies, the development platform was designed and developed. For this, the existing tool-chain described in Figure 2 was adapted and extended where necessary. The DESERVE development system is based on the RTMaps or EB Assist ADTF software framework which already covers different development phases. These tools serve as the primary interface to ADAS related sensors and as a platform for implementing, simulating and testing the associated algorithms. In addition to RTMaps and EB Assist ADTF, a dedicated software framework is provided by means of which different target hardware architectures can be evaluated according to given cost criteria based on a design space exploration and a modelling approach for system on chip. To allow developers to compare different target implementations early in the development process, the above mentioned software framework is couple to a real-time platform featuring a powerful FPGA and options to integrate specific system on chip (SoC) devices, for example, hardware accelerators. Using the combination of FPGA and SoC it is possible to implement the algorithms on different hardware architectures and to compare the results. This workflow is supported by a library of basic building blocks for the FPGA by means of which the target application can be composed and implemented quickly. Being able to use already tested and validated building blocks or software modules in this context greatly facilitates and expedites the development of perception, fusion and tracking algorithms. To provide a tool-chain that is independent of the individual use case, a generic interface to the FPGA is necessary so that the same communication driver on the PC and FPGA interface code can be reused, no matter what sensors are actually connected. In this regard the PC based development framework also serves as a kind of converter translating specific sensor interfaces and protocols to a generic one Page 14

15 Figure 4 DESERVE platform concept for developing ADAS algorithms By means of the DESERVE platform concept outlined in Figure 4, ADAS algorithms can be evaluated on the PC and, in terms of associated building blocks, on different real-time hardware architectures with minimum overhead. As a result of this analysis, early enough in the overall development process OEMs are able to define specific requirements for the target ECU hardware. When it comes to the validation of new ADAS algorithms in the vehicle, for example during fleet tests, a robust and stand-alone real-time prototyping system is required. This system typically has to boot-up as fast as production ECUs and to be remote controlled via the vehicle s ignition key or via dedicated messages on the vehicle bus. For this purpose the PC based development framework in Figure 4 has to be eliminated and the sensors to be directly connected to the embedded controller or FPGA platform. Depending on the sensors used, specific interface modules may be required. In addition, the perception, fusion and tracking algorithms have to be calculated completely on the real-time development system (Figure 5) Page 15

16 Figure 5 DESERVE platform concept for real-time in-vehicle use cases Basically the DESERVE platform concept allows different commercial tools to be integrated. However, to be able to set up dedicated sample applications and demonstrators in the DESERVE context, specific implementations are chosen. Figure 6 shows a prototype of a specific DESERVE development system which is based on the dspace MicroAutoBox II. In the DESERVE project an integrated FPGA board and Embedded PC have been designed. Details about this system are given in the deliverable D2.1.2 Development System. Figure 6 Prototype of DESERVE Development System Page 16

17 Basis on this hard- and software framework, different system variants are used for DESERVE demonstrators which are described in the next chapter. 4. Tools selection and adaptation For the Inter Urban Assist demonstrator (see work package WP4.6) a specific variant of the above mentioned DESERVE platform is used. The associated set up is described in chapter 4.1. Two other vehicle demonstrators are equipped with a slightly different variant of the DESERVE platform. The first one is a passenger car aimed at AEB pedestrian, driver distraction and driver intention functions focussing on urban scenarios. The second one is a light commercial vehicle (LCV) integrating AEB interurban, driver drowsiness and driver intention functions in interurban scenarios. Chapter 4.2 describes the set ups for the associated demonstrator vehicles. Additional information on specific sensor interfaces and options for integrating hardware accelerators are outlined in chapter 4.3. Furthermore, chapter 4.4 proposes a concept for a modular x86 based development platform DESERVE platform based on EB Assist ADTF and FPGA board The Inter-Urban Assist demonstrator is based on EB Assist ADTF that is installed on an extra PC or the Embedded PC which is connected to the FPGA board of the DESERVE platform via a high-speed Gigabit Ethernet interface. This connection, for example, allows video data to be streamed from the PC directly into the FPGA. To process even complex perception and tracking algorithms and to implement multiple signal processing blocks, the FPGA board features a powerful Xilinx Kintex-7 FPGA and 4 GB DDR3 RAM memory. The Inter Urban Assist demonstrator rests upon a flexible, modular and expansible framework. Two parts can be identified: 1) A generic software communication driver for EB Assist ADTF on the PC serves for connecting ADTF with the signal processing blocks implemented in the FPGA. This connection uses the above mentioned Gigabit Ethernet link and the UDP/IP protocol. A matching FPGA code in terms of a MAC layer and UDP protocol implementation is provided for the Kintex-7 FPGA for this. 2) A modular AXI bus infrastructure is used as a template for the application-specific FPGA hardware design [14]. This template can be expanded with new signal processing blocks by connecting these blocks to the AXI bus. To facilitate the implementation, slave and master template hardware modules are provided with the associated framework. Further information about the communication driver and the FPGA hardware architecture can be found in the annex of D Figure 7 outlines the hardware and software set up which is used with the Inter-Urban Assist demonstrator. The software communication driver, that was implemented for EB Assist ADTF, could also be provided for RTMaps Page 17

18 Figure 7 DESERVE platform and DSE framework The development environment described above is used together with the model-based design space exploration approach for system on chip which is introduced in the deliverable D1.3.2 and further described in chapter 5 of this document DESERVE platform based on RTMaps and MicroAutoBox II In this section the development platform architecture used in both CRF vehicle demonstrators is presented. In the first demo vehicle (passenger car) functions for AEB pedestrian, driver distraction and driver intention are integrated. An overview of the implemented architecture is shown in Figure Page 18

19 Figure 8 - DESERVE platform architecture on CRF passenger car A medium-range radar (MRR) and a stereo camera are used for the frontal object perception module. The stereo camera also provides input to VRU and lane recognition modules. Furthermore an interior camera looking at the driver s face is integrated for driver monitoring. A single device composed of a dspace MicroAutoBox II and the Embedded PC, which communicate internally via Gigabit Ethernet, serves as development platform. The Simulink control algorithm is loaded on the MicroAutoBox using a C code generator, whilst the RTMaps runs on the Embedded PC. Each sensor communicates with the Embedded PC via CAN or a proprietary protocol. The second demo vehicle, a light commercial vehicle, contain AEB interurban, driver drowsiness and driver intention functions. The schematic of the implemented architecture is presented in Figure Page 19

20 Figure 9 - DESERVE platform architecture on CRF high end car A long-range radar (LRR) and a stereo camera will provide the obstacle data to the Frontal Object Perception module. A mono or stereo camera is also used for the Lane Recognition module. Two additional internal cameras (one looking at the driver s face and another at the driver s torax) and bioimpedance biological grid sensors are used to implement the drowsiness function. The same development platform as described above will be integrated in the second vehicle Extended interface options to the DESERVE platform In the use cases described above RTMaps and EB Assist ADTF form the primary interface to the individual sensors. However, when validating ADAS algorithms directly in the vehicle, for example during field tests, it may not always be possible to use an Embedded PC with a Windows or Linux operating system. Instead a robust and stand-alone realtime prototyping system is required which can be handled in terms of start-up and shutdown procedures similar to a real ECU. In this case it may be required to connect the sensors directly to the embedded controller or FPGA board of the DESERVE platform. Different options are available for this purpose Sensor Interfaces to the Embedded Controller Application algorithms running on the embedded controller are typically programmed by means of the model-based design approach and Matlab/Simulink. There are different blocksets available to directly integrate sensor data: Radar, lidar, and GPS sensors as well as laser scanners are typically interfaced via the CAN, FlexRay or Ethernet bus for which tailor-made blocksets are available. Electronic horizon data, that means data about the road ahead like slope and curvature information, is based on a digital map and the vehicle s GPS position and Page 20

21 driving direction. This data is typically provided via the CAN or Ethernet bus using the ADASIS v2 protocol standard [15]. For the reconstruction of the electronic horizon in Simulink a dedicated ADASIS v2 HR blockset is provided [16]. Cooperative communication modules such as ITS-G5 radio adapters for V2X communication are not yet available in production vehicles, however the advent is already on the horizon. In the context of DESERVE this topic is addressed in WP 4.5 Cooperative systems functions. To interface V2X communication modules from the embedded controller and Simulink, associated blocksets are currently under development at dspace. Camera sensors may be connected to the embedded controller by means of sensor specific conversion boxes translating, for example, LVDS to Ethernet. However, in typical use cases video streams are directly fed into the FPGA Interface options to the FPGA board The FPGA board of the DESERVE development system provides various interface options: Using a piggy-back concept, application specific hardware modules can be designed and integrated in the overall system. The actual connection to the FPGA is done by means of 12 pairs of differential LVDS lines (2.5 V, 625 Mbit/s per pair) so that even high data streams from radar front ends or cameras can be realized. In addition 200 single ended high-range lines (3.3V) are available allowing complex logics to be added and interfaced with the FPGA. By means of this approach users are able to connect different types of environment sensors to the FPGA in which the associated perception algorithms or specific hardware accelerator modules may be implemented. In addition, the piggy-back concept allows target microcontrollers such as the Infineon AURIX [17] to be integrated. This way, for example, hardware accelerators may be prototyped on the FPGA in combination with the final production hardware. Figure 10 illustrates the interface options to the FPGA board of the DESERVE development system. Figure 10 Interface options with FPGA board of DESERVE platform Page 21

22 4.4. Concept for a modular x86 based development platform As outlined in chapter 4.1 and 4.2 the development platform used with the demonstrators is based on an extended MicroAutoBox II consisting of embedded PC, FPGA board and embedded controller. This system forms a compact and stand-alone prototyping unit with a comprehensive but predefined set of I/O and well-defined processing power. There are only limited options to adapt the number or type of processor, FPGA, vehicle bus and I/O units. From the developer s perspective, the ultimate goal may thus be a more universal and completely scalable development platform. Against this background, based on the dspace SCALEXIO simulator hardware architecture [18], a concept for a more flexible prototyping environment is proposed in Figure 11. Figure 11 - Concept of a modular x86 processsor based development platform The main challenge with such a PC based prototyping system is to guarantee both a high data throughput and very low communication latencies with the associated I/O, vehicle bus and FPGA boards. For example, certain applications require input signals to be captured, corresponding algorithms to be processed and the calculation results to be output within the range of a few microseconds. As a consequence, the performance of the communication bus to interface the multi-core x86 processor with the corresponding plug-in boards is of crucial importance. In the DESERVE project a new high speed low latency bus has been conceived. Details are described in chapter 2.3 of the deliverable D Parameter optimization approach for application algorithms A common approach with electronic control units in the automotive area is to separate the actual software code from the initialization parameters, that are also called Page 22

23 calibration data. By means of these calibration parameters users are able to adapt electronic control units with a fixed application software to individual vehicle models and OEM specific requirements. To support this approach from the tool-side, standards with respect to the access to calibration parameters are available (for example ASAM ASAP 1,2 and 3, [19]). Figure 12 shows a general calibration approach with an electronic control unit (ECU) for a vehicle engine in combination with a test bed automation environment. The so called unit under test (UUT) is in this example the engine plus the ECU, which controls combustion relevant engine parameters such as start of injection, rail pressure, exhaustgas recirculation rate, pilot injection quantities and distances, boost pressure and others. All these parameters are significantly changing the emission and the fuelconsumption behavior of an engine. It is standard in ECU calibration to adapt these parameters in terms of maps, that are defined in the ECU software, in a way that the UUT will meet the emission regulations with the target of minimum fuel consumption. So, the task of the development environment is to simulate the corresponding boundary conditions in order to reproduce the use cases to be optimized and to measure the behavior of the mechatronic unit (engine plus ECU as part of a virtual vehicle, driven by a virtual driver fulfilling a simulated maneuver). Such a development environment can be controlled by a calibration and optimization tool like AVL CAMEO [20], which is connected via standardized interfaces like ASAM ASAP 3 and ASAM ACI. Figure 12 Tool chain for automated calibration using an ECU on an engine test bed as an example Page 23

24 To follow this proven approach in the context of DESERVE an interface between a dedicated parameter optimization tool (such as AVL CAMEO) and the DESERVE development system is planned to be implemented (see Figure 13). This interface is based on the latest technology, the Universal Measurement and Calibration Protocol XCP on Ethernet/UDP or CAN [21]. In addition, it is intended to define a fitting application in order to show the process of defining a test maneuver to be optimized, defining the calibration parameters to be varied in order to reach the desired optimal behavior of the unit under test in the defined maneuver, defining the representative key values to be observed during the tuning process, running the tests according an appropriate Design of Experiments (DoE) plan, modelling the response behavior of the unit under test as function of the calibration parameters, optimizing the parameters based on the models and recalculating the initialization parameters of the application software running on the DESERVE platform. Figure 13 Tool chain for automated calibration of ADAS application algorithms Thus, the boundary conditions are given to make use of the calibration methodology experiences, made in other ECU domains, for the ADAS software algorithms running on the DESERVE-plattform. In case additional requirements will come up during the calibration exercise they will be summarized for subsequent development steps Page 24

25 5. Selection and implementation of an analytical modelling approach for system on chip concepts Identifying the best software/hardware implementation of a system can be performed by an iterative process (see Figure 14). The application designer selects algorithms and defines their parameters. The evaluation of a hardware mapping of these algorithms indicates whether the hardware meets the requirements and may lead to new insights or hints to the application designer, regarding the modification of the application parameters in order to allow a more efficient hardware realization. Figure 14 - Design space exploration framework in the design flow for heterogeneous hardware architectures For a rapid evaluation of hardware platforms, to compare different realizations and to find the best possible implementation, a design space exploration is needed. The evaluation of hardware platforms and derivation of associated hardware costs is a laborious task that can take a long time. To make the design space exploration practicable, cost models can be employed. Usually there are many different possible mappings of application building blocks to hardware (architecture) blocks, as the hardware can be implemented using different technologies. Considering the different characteristics of these technologies, the possibility to explore the design space is needed in order to find solutions that meet the requirements. On the other hand, the evaluation of a software/hardware mapping can deliver design support at different levels in the design process Page 25

26 5.1. Design Space Exploration The design space usually is spanned by a huge number of objectives, for example, implementation cost, power consumption, latency, silicon area, flexibility, etc. (see Figure 15). It is not feasible to implement or simulate a variety of different possible hardware realizations for evaluation and comparison purposes, as the effort would be too high and the simulation of complex hardware would take a long time. Therefore, a cost evaluation and design space exploration based on quantitative cost models will be implemented. The model based cost evaluation supports the system designer by allowing an exploration of the prevailing design space without the need for deep knowledge of the hardware technologies. Thus, the system can be analyzed in early design stages and the feature estimates provided by the cost models can be used to drive the design process. Different hardware platforms impose their own platform specific requirements for the same application while working towards fixed design goals. Comparing the models of, e.g., programmable multicore systems and dedicated hardware, architecture specific attributes have to be considered. To model programmable multicore processors, the work distribution and work balance have to be evaluated, data locality, cache accesses and cache coherency have to be taken into account and the granularity of parallelism is among many other characteristics an important model component to estimate the nondeterministic runtime behavior of multicores due to parallel computing. In contrast, dedicated hardware requires a software model for extracting important algorithmic parameters, which might have a large impact on the later hardware design. In addition to a runtime model, a resource estimation for required lookup-tables, number of used registers and block RAMs and utilized DSPs of the later design is possible. The design space exploration is composed of the following steps: 1) To evaluate the costs of a system, it has to be partitioned into hardware building blocks that can be described independently by specific parameters. Examples for such building blocks are image filters with the number of filter coefficients as a parameter. 2) After specifying the building blocks, a mapping of these blocks to hardware technologies is performed. This determines the cost models to use for evaluating the characteristics of the single blocks. 3) A specification of the system, that means, the required characteristics, has to be fixed. These characteristics could be, for example, maximal power consumption, maximal silicon area or minimal throughput. 4) The cost models are evaluated to compute the estimated characteristics of the hardware building blocks. 5) A report describing the evaluated system is generated. It contains the estimated cost values and indicates, if the system can meet the requirements. From this report the designers can derive design support for different levels of the design process Page 26

27 Figure 15 - Objectives in the design space The design space exploration framework is built on quantitative cost models that describe different possible hardware implementations of application building blocks. Those cost models are collected in a model library. For each application building block, the model library contains a family of cost functions that describes the realization of that building block on a specific hardware technology. A cost function family itself describes different characteristics of the specific hardware realization of the building block. These characteristics include performance (latency), power consumption, and silicon area. However, the model library is flexible and allows the integration of cost functions for additional characteristics, for example, implementation cost, flexibility, throughput rate, etc. The evaluation tool will use all the available cost functions for a basic block. Different cost models, or cost functions, can be specified in different ways. The system will at least operate on the following types: A cost function can be specified as a set of data points, for example derived from data sheets or single measurements. These data sets are used as lookup tables and can provide precise results for a specific combination of input values. Potentially, the system might be able to interpolate the values in the data set to allow evaluation of parameter combinations that were not examined previously. A cost function can be given as an analytical function that approximates the hardware costs and may be derived from different implementations of a hardware block Case Studies In this section, some selected examples of system modelling are presented. In order to illustrate the specific properties of individual architectural concepts, different architecture models for multi core systems and for dedicated hardware are presented. Further information concerning the different models can be found in the stated references Page 27

28 Case study 1: Multi Core Processors Workload model Non-deterministic runtime behavior due to parallel processes, work imbalances, data distribution etc. leads to a difficult algorithmic parameter adaption, which might have a large impact on the later system architecture. Therefore, it is essential to examine the influence of multiple algorithmic parameters on the execution time (see Figure 16). In a multi core system it is of great importance to keep all used cores busy with an evenly distributed workload. In [22], published by IMS, a modelling of the processor workload for the HOG-algorithm (Histogram of Oriented Gradients) on two different multicore systems is presented. HOG are features of small image patches which can be classified with a support vector machine to detect objects, e.g. pedestrians, obstacles etc.. The suitability of two different processor architectures for the computation of HOG features has been investigated. The used architectures are the many core system Intel Xeon Phi MIC, consisting of 61 cores and connected with each other via a bidirectional ring bus, and the Intel Xeon GPP, consisting of 16 core, whereas the cores are split in two NUMA-nodes. For both architectures, the normalized execution time of the HOG computation decreases while downscaling the input image by scaling factor s. Each single processing step of such different image scales has a specific work amount. The challenge hereby is to split the total work amount of all scales into equal sized portions, which can be assigned to different tasks on different processors in such a way, that the workload for every processor is as even as possible. Figure 16: Normalized work amount of the HOG computation over scaling factor s on the Intel Xeon Phi MIC and the Intel Xeon GPP By fitting a function to the normalized execution time (see Figure 16), the split borders can be determined using an adaptive reverse calculation: T Total s max ds T( s) ds s s min s 1 min s max ds s Page 28

29 The usage of this method results in a task splitting scheme, where either multiple tasks are assigned to one scaling factor or one task is assigned to multiple scaling factors. Therefore, the parallelization of tasks is based on a workload model and results in a consistent utilization of all processing cores. Efficient FPGA hardware design concerning the usage of resources and the computation time is highly dependent on algorithmic parameters and needs therefore a deep understanding of the algorithms of interest. In the following two case studies, the classification with AdaBoost and its FPGA runtime model and the classification with a support vector machine and its FPGA resources model is presented. Case study 2: Dedicated Hardware Runtime model In this case study, a hardware implementation and its runtime model of the AdaBoost classifier is presented. AdaBoost is a machine learning algorithm which can be used for objective classification in the automotive environment. A multi staged classifier cascade, whereas each stage consists of the evaluation of different features, is used to decide if an image patch contains a trained pattern, e.g. a pedestrians or cars. Based on a detailed software parameter set extraction of the AdaBoost classifier, a concept of parallelization can be investigated, as depicted in Figure 17. adacascade h1(x) 1 h2(x) h3(x) h4(x) h1(x) const α1 const -α1 const α2 const -α2 const α3 const -α3 const α4 const -α4 N N N N A D D A D D REG REG A D D const k2 REG N+ log2(4) Boosting- Stage 1 const k1 C O 1 M P REG Boosting- Stage 2 H1 (x) COMP & REG Class (x) 1 h2(x) 1 const α1 const -α1 const α2 const -α2 N N A D D REG N+ log 2 (2) C O M P 1 REG REG H2(x) valid 1 REG REG REG Figure 17: Resulting hardware architecture of an AdaBoost stage resulting from a software parameter set extraction These concepts can be used to create a runtime model, which gives the accurate number of cycles for the computation task in dependence of software and architectural parameters: # cycles ( imgwidth imgheight ) log ( M ) 4 cycles # PAR frame Where imgwidth, imgheight is the input image size and M is the number of features per AdaBoost cascade (both software parameters) and #PAR is the granularity of parallelization (architectural parameter). Using this equation along with design goals, e.g. a certain frame rate of AdaBoost classification, the granularity of parallelization can be calculated and therefore the need of FPGA resources, if a resource model is available Page 29

30 Case study 3: Dedicated Hardware Resources model In addition to the runtime behavior of a dedicated hardware, it is of major interest to estimate the resulting FPGA resources of a design. An example for such a quantitative cost model for a support vector machine (SVM) is presented. Support vector machines are classifier that recognize previously taught patterns in respect that an image patch fits into a category or not. Applications with variable accuracy requirements can lead to a significant difference in their usage of optimized FPGA resources. Therefore, a generic VHDL implementation of a hardware design allows the fast adjustment of the design to specialized applications. In this example the parameters cut_mx and cut_ml are architectural parameters for limiting internal word length of special registers. After a set of measurements, it can be seen (Figure 18) that a special relation of cut_mx and cut_ml leads to a saving of a significant number of lookup tables and therefore increases the efficiency of the design. Figure 18: Cost Models derived from synthesis results for a support vector machine, implemented on a FPGA. The architectural parameters cut_mx and cut_ml describe the limiting of internal register width Page 30

31 6. Development method This chapter presents the development methods and guidelines associated with the DESERVE development system described in previous chapters and outlines the benefits in terms of development cost and time savings from the OEM perspective. Basically, the platform concept is based on three pillars which reflect the different development stages and the transition of ADAS algorithms from the prototyping to production phase in the automotive industry (see Figure 19). Stage 1: Figure 19 - ADAS development process using the DESERVE Platform In the research and pre-development phase users typically require highly flexible tools with an intuitive user interface and the implementation of ADAS algorithms may not satisfy hard real-time requirements. Here, PC-based tools such as EB Assist ADTF and RTMaps often constitute the basis for ADAS development. These tools provide a high user comfort and allow developers to implement and verify algorithms directly on a standard MS Windows or Linux PC. Different kinds of sensor/actuator and vehicle bus interfaces are available so that the algorithms can directly be tested in a real environment. However, real-time calculation is not guaranteed, especially with complex perception, fusion and tracking algorithms. In addition, there is no direct support of Matlab/Simulink, AUTOSAR and the model-based design approach for application functions. Finally, PC platforms as described above are typically not tailored for stand-alone, in-vehicle use cases. To avoid a time-consuming redesign of perception, fusion or tracking algorithms when implementing them on the final ECU hardware (production ECU), engineers are looking for ways to evaluate different target hardware architectures according to given cost Page 31

32 criteria already in early development stages. This request is met by the design space exploration (DSE) methodology and the SoC modelling approach. Stage 2: In the second development stage engineers go one step closer to a real-time implementation. Complex and computationally intensive algorithms are shifted to a powerful FPGA to improve the real-time capability. In parallel to this, the FPGA platform allows different target hardware architectures to be evaluated in combination with the selected algorithms. To ensure a rapid implementation of the above mentioned perception, fusion, and tracking algorithms in the FPGA, basic building blocks in terms of a library are provided by the DSE framework. By means of this block-based modeling approach the time and effort for implementing the associated algorithms can significantly be reduced. Using an embedded system platform in this stage featuring both an FPGA and an embedded controller also allows ADAS application algorithms to be designed by means of models so that the associated development time can further be reduced. Compared to the purely PC based framework real-time performance is almost guaranteed, though the user comfort with programming the FPGA may be restricted. Stage 3: The goal of this stage is to go one step further to the final target hardware and to provide a stand-alone, in-vehicle rapid prototyping platform which, for example, can even be used during test drives. This stage reflects the users need to evaluate and experience the driver assistance system directly in the vehicle itself. The standard PC is replaced by an embedded PC that is qualified for in-vehicle use in terms of shock, vibration and temperature, similar to the other parts of the system. This platform also allows the integration of hardware accelerators so that even highly computational intensive algorithms may be tested in the vehicle. It is also possible to interface target microcontrollers of production ECUs and to run certain algorithms there. The complete platform behaves like a prototype ECU which can be operated by test drivers which are not specifically instructed. For example, the platform can be started and shut down via the vehicle s ignition key. The development platforms of all stages can be used together with the model-based design space exploration approach for system on chip and libraries of basic building blocks for the FPGA. By means of this the gap is closed when transferring perception, fusion and tracking algorithms from prototyping to production, similar to the modelbased design approach with application functions using Simulink. Being able to use already tested and validated building blocks and software modules greatly facilitates and expedites the development process. As a result, OEMs are able to define early enough distinct requirements for the final ECU hard- and software Page 32