Model based software development Sample Clauses

Model based software development. Model based design (MBD) and automatic code generation are used for software development at vehicle manufacturers. For some years now, OEMS have used modelling to develop vehicle functions. Model-based approaches are systematically applied to the series currently in product development; the number of functions to be integrated is constantly increasing. Some of the functions developed comprise the entire ECU application software. In each development cycle, the supplier is given the OEMs requirements and test information, that the supplier is responsible for producing software for the model, and implementing it on the ECU. At present, when functions are created via modelling, suppliers still have a high manual workload when integrating them into the ECU [9]. The amount of work involved greatly depends on the software architecture used by each supplier, even when the OEM has specified the communication part of the basic software. In some cases, the software architecture has to be adapted or specially extended. There is no completely standardized software architecture, so sometimes extensive coordination meetings have to be held with specific suppliers. The need for coordination goes beyond just the software architecture. The OEM and the supplier also have to jointly define the description of metadata for integrating functions, such as the interface list for the functions, and the mapping of application signals to bus signals. Thus, the prerequisites for broader and process-safe use of model-based development are a uniform, supplier independent software architecture, and a standardized description of the metadata. The AUTOSAR standard [1] defines software architecture for ECUs, an integration method, and the interchange formats that these require. In other words the AUTOSAR standard [1] largely addresses the requirements for the process-safe integration of model-based functions described above. AUTOSAR divides the application software of an ECU into several software components (SWCs), which communicate with one another via middleware (RTE). SWCs encapsulate the software and give it type definitions, allowing data exchange only via well-defined interfaces. Two mapping steps are needed for integration on an ECU: first the SWC instances are mapped to ECUs, and then the data elements are mapped to network signals for communication across ECUs. For the development of next generation software platforms, many OEMs are taking the first steps towards AUTOSAR architectu...