A typical embedded system design and implementation
2026-04-06 02:04:36··#1
With the rapid development of computer, internet, and communication technologies, embedded system development technology has also advanced rapidly, and the application scope of embedded technology has expanded dramatically. This paper introduces the design and implementation of a multifunction vehicle bus (MVB) embedded system based on ARM and FPGA, with complete independent development from software to hardware. System Design and Implementation Generally, the development process of an embedded system is as follows: Determine the requirements of the embedded system; Design the system architecture: select the processor and related external devices, operating system, development platform, and hardware/software partitioning and overall system integration; Detailed hardware/software design and RTL code/software code development; Hardware/software integration and debugging; System testing. Step 1: Determine the system requirements: The typical characteristics of an embedded system are user-oriented, product-oriented, and application-oriented; market application is the guide and prerequisite for embedded system development. The design of an embedded system depends on the system requirements. 1. Introduction to MVB Bus The Train Communication Network (TCN) is an IEC international standard (IEC-61375-1) for train data communication, integrating the internal measurement and control tasks and information processing tasks of the entire train. It includes two bus types: the Tethered Train Bus (WTB) and the Multifunction Vehicle Bus (MVB). The TCN's position in the train control system is comparable to that of the CAN bus in automotive electronics. The Multifunction Vehicle Bus (MVB) is the standard communication medium used for transmitting and exchanging data between devices on the train. Devices attached to the bus may differ in function, size, and performance, but they are all connected to the MVB bus to exchange information, forming a complete communication network. In the MVB system, according to the IEC-61375-1 Train Communication Network standard, the MVB bus has the following characteristics: Topology: The MVB bus structure follows the OSI model and adopts ISO standards. It supports up to 4095 devices, controlled by a central bus manager. Simple sensors and intelligent stations coexist on the same bus. Data Types: The MVB bus supports three data types: a. Process Data: Process variables represent the train's status, such as speed, motor current, and operator commands. The values of process variables are called process data. Their transmission time is deterministic and bounded. To ensure this delay time, this data is transmitted periodically. b. Message Data: Messages are divided into small packets, which are numbered and acknowledged by the destination station. Message packets and associated control data form message data. Message data is transmitted in command mode. Functional messages are used by the application layer; service messages are used for the management of the train communication system itself, etc. c. Monitoring Data: These are short frames used by the master device for status verification of devices within the same bus, detection of online devices, master transmission, initial train operation, and other management functions. Media Access: The MVB bus supports RS485 copper media and fiber optic. Its physical layer data format is 1.5Mbps serial Manchester encoded data. MVB media access is managed by the Bus Manager (BA), which is the sole bus master device; all other devices are slave devices. The master device polls the port periodically according to a predetermined order. During the intervals between periods, the master device handles occasional requests. Reliability measures: MVB fault tolerance measures include transmission integrity: the link layer has an extended error detection mechanism that provides an 8-bit Hamming distance and can detect bit, frame, and synchronization errors. Fault independence: Copper media is typically configured in full duplicate to ensure independence from device failures. Transmission availability: Availability can be improved through media redundancy, power redundancy, and manager redundancy. 2. The basic requirements of an MVB system are as follows: a. Fully compatible with the IEC-61375-1 (TCN) international standard, supporting the three data types defined by the MVB bus: process data, message data, and monitoring data. b. The system can be configured as: i. Bus Manager (BA) function ii. Bus Manager (BA) function and communication function iii. Independent communication function c. Using an ARM7TDMI processor d. Using a real-time operating system e. Real-time Protocol Stack (RTP) for TCN f. Supporting process data of 4096 logic ports g. Supporting dual-port RAM interface with the host PC104 h. Input voltage 5V i. Operating ambient temperature: -40℃~75℃ 3. Other Requirements The multi-functional vehicle bus MVB system is designed synchronously with the user's train control system, with strict time constraints. II. Step 2: Design the system architecture and coordinate the allocation of hardware/software requirements The embedded system consists of two parts: hardware and software. The hardware architecture is centered on the embedded processor, configuring necessary peripherals such as memory, I/O devices, and communication modules. The software part is centered on the software development platform, providing application programming interfaces (APIs) upwards and board support packages (BSPs) downwards that shield specific hardware characteristics. In embedded systems, software and hardware work closely together to complete the system's intended functions. According to the OSI seven-layer model, the data link layer and physical layer are implemented in hardware, while the other layers are implemented in software, as shown in Figure 1. [align=center] Figure 1: OSI Model of MVB and Hardware/Software Division of MVB System[/align] 1. Embedded Operating System Selection: ● Generally, the following factors should be considered when selecting an operating system for an embedded system: ● Microprocessors supported by the operating system ● Operating system performance ● Operating system software components and device drivers ● Operating system debugging tools, development environment, in-circuit emulator (ICE), compiler, assembler, linker, debugger, and simulator, etc. ● Operating system standard compatibility ● Operating system technical support level ● Whether the operating system provides source code or object code ● Operating system licensing ● Operating system developer reputation Based on the system requirements and the above principles, the VxWorks real-time operating system was adopted in the MVB system. VxWorks is one of the real-time operating systems developed by Wind River Systems (Windriver). Due to its excellent reliability, real-time performance, and kernel customizability, it is widely used in key industries such as communications, military, aerospace, aviation, and industrial control. Its development environment is Tornado. 2. Processor Selection: ● When selecting a processor for an embedded system, the following aspects need to be considered: ● Performance: The processor must have sufficient performance to perform tasks and support the product lifecycle. ● Tool Support: Support for software creation, debugging, system integration, code tuning, and optimization tools is crucial to the overall project success. ● Operating System Support: Embedded system applications require helpful abstractions to reduce their complexity. ● Developer's Past Processor Experience: Having development experience with a processor or processor family can significantly reduce the time spent learning new processors, tools, and technologies. ● Cost, power consumption, product launch time, technical support, etc. In the design of this system, considering all the above factors, processor performance, operating system support, and the harsh industrial environment on the train, the ATMEL AT91 series ARM processor AT91M40800 for industrial control was selected for the MVB system. It is based on the ARM7TDMI core and includes a high-performance 32-bit RISC processor, a 16-bit highly integrated instruction set, 8KB on-chip SRAM, a programmable external bus interface (EBI), a 3-channel 16-bit counter/timer, 32 programmable I/O ports, an interrupt controller, 2 USARTs, a programmable watchdog timer, a master clock circuit, and DRAM timing control circuitry, along with advanced energy-saving circuitry. It also supports JTAG debugging and can reach a clock frequency of 40MHz. 3. Selection of related external devices: After determining the operating system and processor, the related external devices, such as FLASH, RAM, serial ports, etc., can be determined. In an MVB system, the MVB controller (Multifunction Vehicle Bus Controller) is an interface controller between the MVB circuit and the actual physical device. Its main function is to implement encoding and decoding of MVB bus signals and data frames, error correction, and other functions. It is a key hardware module to be implemented in this system. Due to system scale and time-to-market requirements, ASIC implementation is not currently considered. Therefore, an FPGA will be used to implement this key module in the MVB system, as FPGA is the most flexible and cost-effective alternative to ASIC. Considering system requirements, FPGA resources, cost, and availability, Altera's Cyclone series FPGA was ultimately selected, with Quartus II as the development tool. 4. MVB System Architecture Based on the above requirements analysis and selection, the complete system hardware and software architecture is shown in Figures 2 and 3. [align=center] Figure 2: Hardware Architecture of the MVB System Figure 3: Software Architecture of the MVB System[/align] The processor and MVBC communicate and exchange data through Traffic Memory (TM). All control information and data exchanged between the software and MVBC can be found in the TM address space, which is accessible to both the processor and MVBC. Its schematic diagram is shown below. [align=center] Figure 4: Traffic Memory[/align] III. Step 3: Detailed Hardware and Software Design and RTL Code/Software Code Development With the system architecture determined, detailed hardware and software design can begin. 1. Hardware Design The hardware design includes the FPGA design of the MVB controller and the board-level design of the MVB bus system. The key MVB controller design is shown in Figure 5. [align=center] Figure 5: Block Diagram of the MVB Controller[/align] As shown, the MVB controller contains the following functional modules: ● Encoder: Generates Manchester encoding and transmits data frames. ● Transmit Buffer: Serves as a buffer for the data to be transmitted and the CRC detection value. ● Decoder: Receives, performs Manchester decoding, extracts data, and detects data errors. ● Receive Buffer: Serves as a buffer for the received data and the CRC result. ● Message Analysis Unit: Detects master and slave frame timeouts, detects frame errors, and reports error status. ● Status Control Register: Configures the MVBC. ● Master Unit: Supports the MVBC to work as a master or slave device and supports queued message transmission. ● Device Address Reading and Storage Unit: Hardware-defined device addresses can be overwritten with different values. ● Address Logic: Parses the input address of the CPU accessing the MVBC internal registers; generates the output address of the MVBC access TM. ● Bus Multiplexing and Conversion Unit: Handles data transmission within the MVBC. ● Interrupt Logic: Supports 16 interrupt sources. ● General-purpose timer: Two timing output signals can be used for system synchronization. ● Clock generation circuit: Generates the clock and counter for all MVBC operations . 2. Software Design Since process data, message data, and monitoring data use three different communication mechanisms in the MVB system, the module design of the MVB system software is shown in Figure 6. [align=center] Figure 6: MVB System Software Modules[/align] IV. Hardware and Software Integration and Debugging Below, a simple example illustrates the hardware and software integration and verification of the MVB system. Process data in the MVB system is periodically sent. Its communication mechanism in this system is as follows: For the sender, the user application module sends a port's process variable to the process data processing module. The process data processing module updates the corresponding logical port data in the Traffic Memory periodically through the link layer interface module according to the logical port settings. At this time, the sender software's task is completed. The sender's MVBC hardware receives the master frames periodically sent by the Bus Manager (BA). The decoder obtains the values of the corresponding logical ports. After querying the relevant logical port transmission settings in Traffic Memory, the MVBC is automatically set to transmit mode. The data from the logical ports is then transmitted as process data via the encoder in the slave frame, as shown in Figure 7: [align=center] Figure 7: Example of Process Data Communication[/align] For the receiver, the receiving process is the reverse of the sender's. The receiver's MVBC hardware receives the master frames periodically sent by the Bus Manager (BA). The decoder obtains the values of the corresponding logical ports. After querying the relevant logical port receive settings in Traffic Memory, the MVBC is automatically set to receive mode. Upon receiving the slave frame sent by the sender, the receiver updates the data of the corresponding logical ports in Traffic Memory and sends an interrupt signal, thus completing the hardware receiving process. The receiver's software can obtain the updated logical port process data through the process data processing module using interrupts or periodic polling . V. System Testing In this system, system testing includes both software testing and hardware/FPGA testing, which will not be elaborated upon in this article. Conclusion The MVB system described above is now running in the train control system, successfully achieving train operation control, locomotive control, vehicle control, condition monitoring, and fault diagnosis. Of course, if needed, the MVB system described in this paper can be converted into an ASIC design, thus becoming an embedded system within a System-on-a-Chip (SoC). References: 1. International Standard IEC-61371-1 2. AT91M40800 datasheet