The development of on-board computing power platform: functional integration, computing power requirements, software and hardware complexity, communication demand index increased, with the development of EE architecture, gradually moving towards the form of computing centralization, data and energy regionalization. The bottleneck in the development of the vehicle EE architecture and the on-board computing power platform lies in its simple logic processing, the lack of universal software and hardware, the curing of application functions, the non-iteration of software and other unfavorable factors, resulting in the application capabilities of the current generation of intelligent driving products cannot be truly applied to the future intelligent vehicle development process. For the next generation of autonomous driving, it requires strong data processing capabilities, such as the use of Gigabit Ethernet backbone network, 5G high bandwidth, AI computing platform technology; at the same time, open APIs and IDEs can also fuse a variety of sensor data to achieve open sharing of data and APIs, so as to have a powerful application hypervisor APP development integration environment.
In order to achieve the rapid development of intelligent in-vehicle software, it includes a service-oriented design process, responds to the rapid iteration of new scenarios that appear in the continuous testing process, meets the needs of thousands of customers, and shortens the entire vehicle development cycle. In addition, through the rapid deployment of software, software and hard separation, software reorganization, and application addition, the effective integration of external resources and the enrichment of vehicle services are realized.
1. Design of centralized domain control architecture based on SOA
For high-performance computing platforms, usually using a centralized cross-domain fusion of domain control architecture, the need to achieve more than exist in the interconnection class function or direct interaction between the domain control to achieve the function, through a single brain HPC + area control architecture scheme, the area controller is required to assume the proxy function, often bound with the service-oriented SOA architecture for design, which will lead to a high degree of flexibility and scalability of SOA in the next generation of centralized domain control architecture Penetration will be very high.
Using the SOA design concept, it decouples software and hardware in SOA services, controls IO virtualization, and servitization. The definition and deployment of multi-level services in the vehicle is a common design scheme for the next generation of domain control platforms. For the centralized domain controller platform, the design process needs to integrate vehicle control, automatic driving, intelligent cockpit multi-domain integration, hardware resource sharing, and real-time data sharing domain control hardware: the most advanced chip in each field, through high-bandwidth and low-latency Switch cascade software, in addition to achieving computing power expansion and multi-domain integration, can also achieve high-security, hard real-time OS, middleware and application operation environment domain control and communication between other control units.
The following figure shows a physical architecture based on the central computing unit + regional control unit, for the realization of the real central computing platform, it is also necessary to set up 1- multiple area controllerS PDC, VDC, etc. the ring network architecture is used to realize the function of data and energy gateways, thereby reducing the number / length of wiring harnesses, optimizing the intelligent energy management mode, and effectively improving the software-based function of the central domain controller.
In addition, for the above big data interaction, it is also necessary to set up the corresponding switching transmission unit for corresponding data exchange. These switching units include PCIe Switch, Ehternet Switch, TSN Switch; among them, PCIe Switch satisfies the real-time big data interaction between computing chips; solves the pain point requirements of high bandwidth and low latency to achieve any end-to-end data transmission, and the bandwidth is above 20Gb/s, physical isolation, and single point failure does not affect system failure. The TSN Switch features bidirectional transport protocol conversion from CAN/CANFD/LIN to Ethernet. Realizes NC/EE/BE different priority data forwarding and data exchange in the TSN protocol. Compatible with other TSN devices that comply with in-vehicle specifications. Ethernet Switch is used to connect switches between Ethernet or between Ethernet and Fast Ethernet, which saves resources and time and increases the rate of data transmission through physical addressing, network topology, error checksum, frame sequence, and flow control.
Here we need to explain that the centralized domain control design needs to support the technical carrier of the SOA implementation. It includes the definition and implementation of service-oriented communication SOCs: DDS, SOME/IP, etc. and service interfaces; at the same time, the service-oriented software architecture supports SOSA: such as AP, which is a solution that can meet certain real-time requirements of functional safety; service-oriented reuse sharing architecture design SORS: top-down and bottom-up combination to ensure service reuse sharing and expansion;
The product of the SOA paradigm consists of the code/model of the service implementation, integrating a controller (service code + SOC code + support for the SOS system environment), and the vehicle consists of a subsystem composed of this controller. The following diagram shows a typical flowchart of soa-based soa-based system design to code implementation model for domain control.
2. Endpoint testing based on SOA services
1. Terminal test process based on SOA service
For the next-generation autonomous driving system SOA, in addition to clearly grasping the definition of SOA itself, it is also necessary to know how to test SOA, understand what the technical product of its implementation is, what is the implementation entity based on SOA, and how the new EE architecture based on the SOA concept will be tested. This section describes in detail the testing process and methodology for SOA.
To have a clear understanding of the SOA testing process, you first need to master the SOA design process. It consists of 9 sub-processes, as follows:
A1: Vehicle Futures List definition;
A2:Usecase analysis of Feature;
A3: Logical Subsystem Definition;
A4: Functional requirements specification;
A5: Definition for SOA services and service interfaces, where the service contains which functions are applicable as services from the perspective of feasibility and necessity, defining their granularity, basic services, extended services, application services, and the need to define service interfaces;
A6: Network topology definition; including defining the topology structure and the choice of required communication technologies;
A7: Function assignment and service deployment;
A8: Service-oriented and signal-oriented communication design;
A9: Development (AP, CP, ROS, COTS and other platform selection), integration, testing;
For SOA test objects, they are tested in a tree structure, as shown in the following figure.
First of all, it is necessary to carry out vehicle-level analysis to make the whole process more intelligent (such as automatic/assisted driving, human vehicle monitoring), more friendly (such as voice control, entertainment surfing), and more flexible (such as function upgrades); secondly, it is necessary to conduct system-level analysis, including the traditional signal-based distributed function implementation, based on high cohesion and low coupling service and service combination implementation, to achieve hybrid heterogeneity.
At the next level is component-level analysis, including ECU function and morphological analysis, that is, to achieve "class" differentiation. The first is the core level, the brain level, including domain controllers, computing platform multi-system multi-processor AP+CP, application service providers and consumers, and large gateways. Bridge hub, the new generation of area controllers (VIU class), a large number of communication ports and IO at the same time, CP; regional gateway / proxy gateway (S2S), taking into account the regional part of the control function, to provide basic services and extended services. Excessive continuation, sandwich layer: chassis control, passive safety, typical embedded systems, functional safety is a system with high real-time requirements; the terminal layer contains sensors and actuators.
2. Terminal test methodology based on SOA service
For SOA testing, it is first necessary to establish and adapt the test specification. We know that the layering of the entire test includes components, systems, and real vehicles. Among them, the component and system levels include whether the behavior such as verifying the function is consistent with the requirements specification; for the actual vehicle, it is necessary to confirm whether the user, laws and regulations and other requirements are met.
The key to testing is to develop test cases based on requirements specifications, user use, industry regulations, and standards; develop test cases and objects under test based on experience and scenarios. Incremental and variable requirements include new vehicle communication technologiesSOME/IP, DDS, TSN, synchronous CAN, etc.; new test categories include service interface testing; new forms and carriers include services, S2S, heterogeneous domain control/HPC, ZCU/VIU/PDC; new functions and application scenarios include personalized configuration, remote diagnosis, network/data security, etc.
The development of the entire test specification includes new in-vehicle communication technology testing, service interface testing, and service "logic" testing.
These three major tests include TC8 protocol conformance testing inSOME/IP, custom requirements specifications and configuration specifications, development test specifications, robustness and scenario tests derived from experience; DDS based on custom requirements specifications and configuration specifications, development test specifications, such as end-to-end latency, QoS configuration incompatibility, etc.; TSN tests for AS, development and test specifications and startup, latency, stability and other aspects. Service interface testing includes conformance tests for developing basic services, extending services, and application service interface definitions based on service interface specifications, and testing for message timing, data legitimacy, and robustness. Service logic testing is mainly based on the needs of different levels to establish component-level, system-level and real vehicle-level test specifications, the more to the upper layer, the higher the degree of test case reuse. Based on the characteristics of SOA, the implementation mechanism and application scenarios are combined to increase the use cases at different levels, such as the scenarios that can cause resource consumption, the performance test of end-to-end service stability and interaction response, and the performance test of service and signal conversion.
3. How do I set up an SOA test environment?
First of all, the ECU "class" differentiation under the new architecture, the traditional "three major pieces" (including chassis, body, power) control mode from the original perception control all-in-one machine to the function to achieve "high cohesion" & "low coupling" trend, software iteration is getting faster and faster, ICT and other industries implementation technology and process technology will be more injected into the entire change challenge.
The impact is that in component-level testing, automated testing for the core controller is more important, and the complexity of the test environment depends on what level the ECU is at. System-level testing is even more important, and environmental complexity depends on how the functionality is implemented and the allocation scheme. Vehicle-grade testing is a certain degree of weakening of the traditional large VV HIL. In general, the proportion of conventional hardware IO in HIL test systems is greatly reduced, the type and quantity of communication resources are more, and special solutions are used for special needs; such as TSN, LVDS and other special communication tests. For HIL test system software and engineering development, the adaptability and scalability of test system software are more critical, which can mainly reduce the secondary development workload: such as some/IP, DDS, HTTP, MQTT and other protocol support. On the other hand, the development of the simulation environment will increase: for example, it is necessary to build some/IP, DDS "reference ECU" "interactive behavior" open-loop model. Support for CI/CT: including system remote/cloud control, real-time monitoring and self-protection; support for remote brushing and coding of the object under test; support for the association of software iteration change points with test scopes.
For the entire SOA test, the test methods mainly include virtual ECU test technology, which requires understanding of the implementation principle, its adaptation object analysis, prerequisite analysis, and implementation of key technology construction. At the same time, the mainstream toolchain of the automotive industry is used to effectively test the front-end model and software code, and in addition to the "online" automated test, the "offline" test based on data is also optional and complementary. In order to ensure that the test granularity is finer, it is possible to move the test work forward, build quickly, adapt strongly, and adapt to agile development "suitable" for the automotive field.
The following figure shows an example of a typical service interface test specification during the development of an SOA-based service model. The overall SOA test specifications, steps, and requirements results can be seen.
4. Summary
This article first describes the soa-based centralized domain controller design logic, architecture, and correlates how the design will meet the soa validity test in the second part. The entire development process of SOA requires a similar data closed loop, that is, the entire process from design, development to testing needs to have a complete correlation. If it is a cooperative development model, it is necessary to distinguish the definition of responsibilities between the OEM and the supplier to ensure that the final test results meet the development requirements expectations. Of course, whether from development or testing, the entire service-based toolchain should ensure consistency and avoid bias in results caused by marginal inconsistencies.