Recently, many friends have sent me private messages to the editor who don’t know much about some issues related to automotive software, so orange will make a summary for everyone in this regard. Interested friends can come and learn about it together.
Testing is an important part of the car development process. As software is increasingly used in modern vehicles, so does the need for rigorous software testing methods. A special aspect that has been overlooked is the practice of software testing in the commercial vehicle sector with many unique features.
1. Definition
The European Union defines a "commercial vehicle" according to the design purpose of its structure and type of equipment, any motorized road vehicle capable of carrying: a) more than nine persons, including the driver; b) cargo and standard fuel tanks [1] is classified as a "commercial vehicle" ".
Light commercial vehicle (LCV) is the official EU term for commercial vehicles with gross vehicle weight ≤ 3.5 tons. Vehicles that meet this category include vans, minibuses and light trucks; heavy commercial vehicles (HCV) are those with gross vehicle weight > 3.5 tons. The official EU term for commercial vehicles, vehicles that fit into this category are vans, trucks, tankers, etc. A broader definition of HCV also includes heavy equipment and machinery including agricultural vehicles (tractors, harvesters, etc.), and construction vehicles (rock drills, bulldozers, wheel loaders, etc.).
The scope of this study covers both light and heavy commercial vehicles.
Market size and potential
Commercial vehicles occupy a specific and non-negligible market share in the automotive industry. According to ACEA (European Automobile Manufacturers Association) data, in 2012, more than 200,000 commercial vehicles were produced worldwide, accounting for 11.3% of the EU market. Compared with 2011, the EU-produced LCV/HCV export revenue in 2012 increased by 22.9%[3].
Likewise, Frost & Sullivan [2] pointed out that the demand for light commercial vehicles in Europe has far exceeded that of other continents. Hybrid commercial vehicles, in particular, will occupy a major market share in the near future. Most of the hybrid LCVs that will be available around 2016 will include electric versions of the Mercedes-Benz Sprinter and Ford Transit Connect.
The two models are expected to account for one-third of the European hybrid light commercial vehicle market.
Regardless of production statistics, with a compound annual growth rate of 24% worldwide [2], all major regions are expected to maintain the growth rate of commercial vehicle telematics.
2. Overview of Quality Assurance Challenges
The trend in modern automobiles has shifted from purely mechanical to widespread electronics.
A rough estimate of the number of Electronic Control Units (ECUs) in a typical modern car is about 70, including more than 1 million object code instructions and nearly 1 GB of software [4].
This trend is also reflected in the development of commercial vehicles. The increasing use of embedded controllers has more or less acted as a catalyst for telematics in commercial vehicles.
The value creation of such vehicles is largely determined by embedded software, which not only adds cost and complexity, but also increases the potential pitfalls of embedded software. While mechanical defects are decreasing gradually, defects caused by electronic systems are increasing rapidly [5]. Advances in transmission, by-wire, navigation, ergonomics, and infotainment technologies require stringent quality assurance measures in embedded systems approaches. The same is true of the global auto industry.
However, the commercial vehicle industry is particularly affected by stringent regulations aimed at improving environmental protection, safety (ISO 26262/IEC 61508) and quality assurance measures (IEEE 610) [9].
In order to meet the current target, the engine, chassis and body under development will be completely replaced. The questions to be addressed are: what should be used in advanced embedded systems in commercial vehicles, and how to apply appropriate quality assurance strategies.
3. Visual Testing Domain Features
This section describes from a testing point of view: the characteristics of the commercial vehicle domain are quite important.
3.1 High security requirements
Safety is an extremely stringent requirement for commercial vehicles.
The aim of the European Road Assessment Programme is to reduce the probability of road accidents in Europe to zero fatalities by 2020. - The project is called Vision Zero. Related standards, such as ISO 26262 [9], also put pressure on the automotive industry to develop protocols, tools and best practice guidelines for making engineered roads safer.
There are other safety measures specific to commercial vehicles. For example, heavy-duty trucks should pay more attention to rollover incidents directly caused by inadvertently exceeding the rollover threshold while driving. As a result, manufacturers have invested considerable time and resources in establishing safety measures (eg, roll stability control systems) to deal with this situation in heavy commercial vehicles.
3.2 High demand for reliability
Reliability is concerned with the quantification of failure rates in a system. Software reliability is the probability that the software will not fail within a certain execution time.
So far in the automotive domain, reliability has not been formally regulated compared to other embedded systems domains such as avionics [4].
In addition, commercial vehicles should perform well in tough, safety-critical environments, such as heavy trucks loaded with tons of fuel and rock rigs drilling irregular surfaces. Therefore, low reliability can lead to dangerous situations during operation.
Their life expectancy is longer than normal passenger cars. All of these situations place additional demands on the reliability and durability of the vehicle.
3.3 Real-time Electronic Control Unit (ECU) Functions
The complexity of commercial vehicle embedded systems is largely due to the fact that most other classes of automotive systems do not address real-time and interface constraints.
A study of automotive software engineering practice [4] shows that most vehicle functions are implemented by hard and soft real-time tasks.
In extreme cases, up to 95% of the functions are simulated by hard real-time tasks, most likely commercial vehicles, for which multimedia functions and human comfort functions like discrete-event soft real-time functions are less important.
In addition, functions that require neither soft nor hard, but sometimes in between, are often modeled as hard [4]. Typical requirements include priority relationships and jitter between tasks.
Time constraints, such as deadlines, can vary by up to three orders of magnitude within a single application, typically from milliseconds to seconds.
Testing in this area is extremely challenging because the correctness of a system depends not only on its logical correctness, but also on the exact time when the results are generated.
It is often difficult to track down and reproduce errors because it requires a high degree of precision in deciding when to simulate the system and when to expect a response.
3.4 Staggered configurations and variants
The product volume of commercial vehicles is usually smaller than that of passenger cars. Moreover, users often require more technical specifications such as engine torque, payload, etc. [5]. As a result, automakers often use product variants to satisfy a larger customer base, thereby increasing market share and product production. Consequently, embedded systems for commercial vehicles include components from multiple suppliers and exist in a large number of configurations and variants.
This results in a huge workload in terms of testing campaigns to cover huge product variants.
3.5 Distributed Development
Due to inconsistencies in commercial vehicle component variants, it is impossible for automakers to develop all of their in-house products. Instead, they prefer to rely on the proven expertise of third-party vendors.
For this reason, and in part because of strict cost requirements, the development of commercial vehicles has been largely fragmented and outsourced [6]. This creates many supply chain relationships that make it difficult to regulate up-to-date and consistent across all levels.
In fact, manufacturers end up failing to design the details inside a "black box" component [4]. This adds to the complexity of locating component test errors at the unit and integration levels.
4. Automotive software testing practice
This section outlines the practice in automotive software testing.
This study looks at the commercial vehicle sector, but the findings in this section apply to the entire automotive industry.
Note that the lessons in this section are limited to mainstream practices used by major celebrities in the automotive industry. There are other practices, including research and technological innovation, that were excluded from this study.
Here, our aim is to provide some clarity on the main practices of the automotive industry.
4.1 Model-Based Development and Testing
Based on the author's experience working with major automakers and suppliers, there is a strong momentum for model-driven engineering in the development of modern vehicles. This includes all stages of the development process, from requirements to verification.
A model is an abstract view that represents a part of a system's behavior.
Engineers use domain-specific modeling techniques to model system behavior very early on, enabling them to rapidly develop systems by automatically generating code from the models and testing the system before implementation.
The basic idea of model-based testing is to apply a selected algorithm to automatically generate tests from the model [13] instead of manually creating test cases.
In addition to being highly automated, model-based testing helps maintain traceability between system models at the abstraction level and traceability between test outputs at the system execution level. This makes the source of errors easier to trace and reduces the effort and cost of the overall testing activity.
4.2 Cycle X Test Levels
The different phases of model-based development and testing are manually described using the V-model recommended by the automotive SPICE development standard (see Figure 1).
V-models are typically designed to perform different levels of testing work that fit into the development process.
These levels of testing are called Loop Model, Loop Software, Loop Processor (HIL) and Loop Hardware (aka Loop X [7]) tests and are described below.
MIL (Circular Model):
MIL provides testing of a model of a system (or subsystem) available, and the model and its environment can be simulated without any physical hardware. The input and output interfaces of the system are defined for different test scenarios.
Input signal values are simulated and the corresponding output signal values are compared to the expected values defined in the scenario.
MIL testing enables functional verification of systems very early, even before implementation.
Since the model and environment are similar on the same machine, there is no need for real-time hardware.
SiL (Cycle Software):
SIL conducts tests of executable code segments (or implementation segments).
Operation on the same machine is similar. Therefore, this level does not require real-time hardware.
All details about storage capacity, data structures, etc. are controlled by the simulated environment. This ensures that any "runtime errors" (buffer overflows, division by zero, illegal type conversion errors, etc.) are detected at implementation time.
In addition, it enables system behavior to be verified by running the same test scenarios in MIL.
PIL (loop handler):
PIL ensures that the implementation can be tested when running on a target processor or a target processor simulator.
The execution environment is still usually simulated by a dedicated real-time emulator.
Failures at this stage can be tied to the target compiler (linkage, optimization options, etc.) or to the target processor architecture.
MIL and SIL test scenarios can be used here to compare with the original results, ensuring that the code functions correctly, even after it has been compiled and run on the target processor.
HiL (loop hardware):
HiL enables implementations that are now embedded in actual hardware (ECUs) to be tested. This is done by linking the ECU to a dedicated real-time simulator that illustrates the actual input/output of the ECU to the test environment of the analysis results.
Other parts of the embedded system that the ECU uses to communicate can still be simulated.
However, they interact with real electrical signals.
Tests in HiL can analyze code and hardware integration in a real-time environment.
This level of failure is also associated with low-level communication between the input/output interface and real-time communication with other parts of the embedded system.
Test scenarios for MIL and SIL can be used to verify previously observed system behavior.
The above is the relevant knowledge about automotive software testing shared by Lanya editor orange. I believe that everyone has a basic understanding. If you have any questions about professional issues, you can contact the professionals below to answer them. helped.
Next
No.
