Research on spacecraft embedded software CAN bus testing methods
With the development of aerospace electronics technology, aerospace electronic equipment has become more and more integrated, and bus technology has begun to be used more and more widely in the field of aerospace electronics. The working environment of the spacecraft is harsh, and space radiation, electromagnetic interference, etc. may affect the normal operation of the software through hardware. In order to achieve the goal of "one failure to ensure business continuity and two failures to ensure spacecraft safety", the on-orbit reconstruction function of the software is ensured , bus reliability and safety have become necessary guarantees for on-orbit spacecraft. As a serial data communication protocol, CAN bus is widely used in the communication of ground, satellite and rocket-borne subsystems of aerospace electronics due to its reliability and real-time characteristics such as high bit rate, high anti-electromagnetic interference capability and detectable misalignment. Function(1-6).
Spacecraft embedded software is closely related to hardware. The characteristics of the hardware operating environment and the diversity of hardware significantly affect and restrict the development of software (7). The design pattern of "hardware standard selection and software-defined functions" is widely used. The establishment provides sufficient guarantee for bus universal testing. In order to ensure the implementation of CAN bus solutions and ensure software quality, more and more automated test systems based on CAN bus have been proposed (8-10), but the test methods and use cases of CAN bus are rarely mentioned.
CAN bus communication hardware architecture
The satellite CAN bus generally adopts a dual-redundant bus network structure, including two CAN buses A and B. The management control unit and other lower units form communication nodes. After the power-on initialization is completed, the CAN bus processor of each node of the bus waits for the management control unit to send instructions, broadcasts and polls, and completes the reception and response of data according to the format agreed upon by the communication protocol.
According to the difference between the main control chip and chip expansion, the CAN bus communication architecture mainly includes three forms: CUP+control chip+driver chip, FPGA+control chip+driver chip, and FPGA (CAN soft core)+driver chip. The bus driver chip usually uses PCA82C250, and the control chip uses SJA1000 series chips. As shown in Figure 1, the CUP+control chip+driver chip architecture (Architecture 1) multiplexes the data read and write signals of the SJA1000 chip through the chip select, identifies the bus occupancy according to the interrupt signal of the external bus, and establishes the preset bus priority. Communication strategy for bus simultaneous occupation. As shown in Figure 2, the FPGA+control chip+driver chip architecture (Architecture 2) realizes the independent operation of dual SJA1000 chips based on the parallel operation characteristics of FPGA, processes dual bus transmission and reception at the same time, and analyzes and processes the instruction cache register according to bus priority sorting. As shown in Figure 3, in the FPGA (CAN soft core) + driver chip architecture (architecture 3), the FPGA integrates the CAN bus control function, which reduces the asynchronous interaction between integrated circuits. The soft core solution architecture provides redundant backup of registers and abnormal communication. The reliability and security of processing strategies impose stricter requirements.
Embedded software CAN bus testing
The testing of the CAN bus needs to be based on requirements, fully covering the performance, functions, and interfaces of the product. Key test cases are set for easy and frequent problems. Test cases involving data boundaries must cover the boundaries. For satellite-borne embedded software, it is necessary to test the software at a high level. Focusing on reliability and safety in frequency, long time, and harsh environments, CAN bus test implementation focuses on the following five points:
(1) Test the software’s self-correction capability when the length, format, and content of data received by the bus are abnormal;
(2) Test the overflow prevention capability of the software receiving data buffer when the bus is overloaded;
(3) Test the autonomous reset and initialization function of the bus interface when the bus is blocked or closed;
(4) The test meets the time performance indicators while retaining a reasonable time margin;
(5) Test the software's ability to resume normal operation when the bus returns to normal after the intensity of instantaneous intensive data transmission exceeds the software's processing capabilities.
Based on the implementation of the key points of CAN bus testing, test cases are designed for the performance, function, reliability and security of the CAN bus interface, and the correctness of the software design is confirmed through the timing signals captured by the oscilloscope and the instruction count of the telemetry information. For functions that are inconvenient for black-box testing, the VTEST test platform is used to monitor relevant registers in the software to complete gray-box testing. The performance test of the CAN bus mainly tests the bus baud rate, bus response and frame interval time, the chip reset pulse width of the bus control chip, and the read and write timing of the bus control chip. The performance test of the CAN bus can be detailed Please refer to the manual of CAN2.0 general protocol and peripheral control chip, so I won’t go into details here.
The functional testing of the CAN bus is mainly carried out from three aspects: protocol communication, error protocol communication and bus switching strategy testing. The functional testing has the same test items for different architecture platforms. The test examples are shown in Table 1.
For the reliability and security test design of the CAN bus, the monitoring of the internal registers of the bus control chip cannot be achieved through ordinary black box testing. This article uses a virtual platform built by VTEST to realize the monitoring function of the required registers. The test uses, for example, As shown in Table 2. The VTEST test tool simulates the embedded virtual test platform, which can simulate the interface chip of the embedded software. By importing the source code under test, it can implement program target code instrumentation, interface monitoring, statistics of target code program statements and branch coverage information, and analysis of the target code. Execution (11).
Software testing is an important guarantee for software products. Sorting out and summarizing common multiple test items can effectively curb the emergence of related problems. This article starts with the common architecture of CAN bus to sort out the test points and design test cases, hoping to provide reference for relevant engineers.
Review Editor: Liu Qing
#Research #spacecraft #embedded #software #bus #testing #methods
- Analysis of electrostatic surge protection scheme for NB-IoT device antennas
- New product launch | Xianji Semiconductor joins hands with VeriSilicon to break through multimedia MCU performance and create a new generation of digital instruments
- Innovative expanded beam fibre optic connector technology
- Key Trends in Gas and Particulate Sensor Technology
- What is the pipeline of a superscalar processor? What are the characteristics of superscalar processors?
- Current situation and development under accelerated increase in N-type penetration rate
- How to solve the frame loss phenomenon of industrial cameras?
- New MOSFET product family for automotive and industrial solutions
- The integration of generative artificial intelligence and the real economy promotes the development of new productivity
- TSMC rose by more than 5% and hit a record high. The demand for AI is strong and is expected to grow by 50% year by year.