WP1 will orchestrate the recording and structuring of requirements submitted by partners at the system, component, and method development levels. Throughout the project, partners will develop architectural elements in their focus areas, which will be mapped and refined. All elements will be integrated into a project-wide system architecture, defined and continuously updated in this work package.
The implementation is the most resource demanding part. For the implementation, many different aspects are important, such as resource requirements, hardware target, safety and real time requirements.
First, based on the architecture (cf. WP1), the architecture is refined into Micro-services. Usually, there are also different solutions possible, how to break down the architecture into several Micro-services. Therefore, it is also possible to implement more than one Micro-service for the same architecture. This makes especially sense when there are dependencies between the hardware target platform and the Micro-service. Especially, safety and real time requirements have a strong impact on the choice of the HW target and the middleware. For example, different solutions are needed, when the architecture is deployed on a microcontroller (µC) or on a microprocessor (µP). Other dependencies are coming from the communication middleware e.g., SOME-IP or CAN or DDS or http.
An end-2-end API-stack is planned to establish an efficient function abstraction. Existing initiatives (s. COVESA, Eclipse) might support the harmonization effort in this project. Therefore, the collaborative approach of this project is the basis for the re-use of the Micro-services and the sustainability of the results.
WP3 will integrate the components developed in WP2 into various system and test environments, ranging from unit tests to integration tests. These builds the basis for the V&V (integration testing) in WP4 and final use case specific demonstration (system testing) in WP5.
The integration in WP3 follows two dimensions. First for various building blocks the integration respectively the compatibility between the stack or cloud component (S-BB) with the corresponding engineering support BB-(C)E&ST will be ensured. These fosters that the envisioned holistic engineering framework addresses the in-vehicle and cloud building blocks providing a tangible design support. The second dimension is provided by the integration of different buildings block with the underlying microservices, e.g. from different functional clusters. This way the compatibility
between, e.g., the communication abstraction (E1) as well as the microservice orchestration (I1) is working together.
But also, for building blocks within a functional cluster, such as between in-vehicle communication (E1) and cloud communication(E2). On that note, it should also be mentioned that these activities will be used to ensure compliance between the stack building blocks (S-BB) and the specified standards (BB-SC).
The work in WP3 will be split into two parts: in the first part the integration schema will be designed, based on the overall system and building block architecture developed in WP1. The interfaces between components will be defined and validated. Integration of individual components in the lab environment will be realized in the second part.
The specific goals of WP3 are therefore to:
The outcome of the WP3 will represent the integrated systems ready to be tested and demonstrated in WP4 & WP5.
WP4 will verify and validate (V&V) the software and systems developed in WP2, and integrated in WP3, before being demonstrated in WP5. This includes developing suitable test concepts, test routines including test adapters and stubs, and the design and development of the appropriate test environments and test systems.
Testing will be done on multiple levels:- on component level (unit testing, interface testing),- in semi-integrated systems (integration testing, functional and non-functional tests)- in fully integrated systems (full vehicle stacks, cloud stacks, tool-chains).
Supporting the “shift-left” paradigm, the focus in WP4 will be on developing methodology and technology to start with testing systems as early as possible in the development process, starting with models (MiL), early prototypes including mock-ups, and Software executed in other than target platforms (SiL). An important step in this direction is testing in virtual environments. Depending on the V&V focus, this might include high-fidelity simulation of interacting systems, actors and environments, which for this reason will be developed and matured in WP4 as well. Improved simulation accuracy shall allow to verify to a certain extend aspects like performance, safety and security of the software under test before the full system is at hand.
In order to achieve the goal of SDV – to drastically reduce time between writing code and deploying to vehicles via OTA
WP4 is strongly linked with T1.3 (Provision of specifications as well as demonstration and test scenarios) and with T2.3 (Refinement of API-implementation after testing and API harmonization) and T3.1 (deriving test stubs/adapters/mocks from integration architecture)
The “software-defined” vehicle is a paradigm that is usually associated with the introduction of new user-centric functions, connectivity, and further means to improve the driving experience. Especially with introduction of act-by-wire and upcoming vehicle compute centralization a new level of vehicle motion and dynamics are enabled. This particularly applies for functions that operate in dynamic driving situations where a joint control can provide added safety, comfort, and agility. The functional abstraction of the chassis feature is addressed in this work package.
The project aims to create a logical architecture for managing different use-cases like “Plug&Charge”, “Cockpit”, “VMC” and “ADAS”. This architecture will consist of building blocks with interfaces that allow for the integration of different functions in a closed loop system. These interfaces will have well-defined quality of services, including timing. The project aims to align over different suppliers to come up with a harmonized understanding of the APIs and aims to contribute them to international standards (e.g., ISO/PAS) and open source initiatives (e.g., COVESA). In the dissemination work package, a publication of the interfaces and logical architecture is foreseen.
Introducing well defined interfaces between the architecture building blocks of the logical architecture, a meta-model for shifting functionality from microcontroller to microprocessor shall be developed. As part of the meta-model development, various aspects such as latency, sampling rate, etc. are to be assessed. However, the expected, growing flexibility and the potential for easier updates in the future are so encouraging that this project suggests conducting a concept evaluation and defining possible APIs. Over time, customers will anticipate performance upgrades for their vehicles even after purchasing them. This is particularly relevant for motion control in (semi-) automated driving and improving charging performance, including in-car gaming.
New features like map services for road roughness, in combination with the vehicle motion control, can be flexible offered after the vehicle purchase. Besides those directly related features also new user experience features such as in-car-gaming experience can be offered through the flexible and safe control of motion actuator (e.g. steering-wheel actuator). This is very interesting for the customer and prepares a new value creation process: the SW-upgrades will be enabled like the app-business we know today from the smartphones. We are used to choose our apps well after we have purchased the smartphone hardware. A comparable market is to be created for the vehicle. The “Shift2SDV”-project proposes to create the foundation of this new eco-system, which will be based on open APIs like the smartphone, which is based on the Android / iOS APIs.
The demonstrator WP has the objective, to show all relevant concepts and methods developed within Shift2SDV project.
WP6 aims to show how a transformation towards SDV can be achieved: starting from monolithic software stacks and E/E architectures in the vehicle towards dynamic software systems that change over the life cycle and make up a software defined vehicle. The focus is on the building blocks and demonstrations developed in this project, considering not only technical but also social and community-related aspects. This transformation path encompasses the entire life cycle of the vehicular software and goes beyond this through continuous further development of the software, which is to be used across all vehicles and models. The classic V model, which begins with planning and extends to the finished (validated or certified) software, does not fulfil the requirement that a connection between the development teams and the SDV must also be guaranteed after the SOP. This not only changes the way (processes, workflows, methodologies) and the tools that are used (entire toolchains) to develop the software, but also the roles of the companies and people involved in the development (new business models, changed value chains, as well as new working methods of the development teams). Responsibilities are also shifting, and boundaries are disappearing (the cooperation of many people involved in development, operation, maintenance and other service providers is necessary). An SDV is a system of systems in which everyone involved works in parallel and is in constant dialogue with each other. This requires new skills and approaches from those involved. These new skills very likely include the focus on data with actual data orientation, i.e. the shift away from functions centricity to data and the understanding that the more complex a system tends to become, reduction of complexity is more important than its management. Without rigorous management systems automatically become more and more complex.
It seems clear that this transformation cannot be achieved overnight. The way in which this transformation takes place must therefore be seen as one of the key challenges on the road to SDV. A starting point could be to separate data and functions right at project start and work with adapter functions, rather than applying a strangler pattern-type approach. This transformation to data orientation can be integrated into the existing workflow harmoniously and step by step, putting existing solutions on new footing, supplementing them where necessary and, if not otherwise possible, replacing them with new approaches or technologies. This should guarantee that all those involved recognize themselves in this transformation, actively support it, are open to the new challenges and move towards SDV together. In particular, the considered steps to achieve this transformation are:
