2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
Embedded network is a network system used to connect various embedded systems so that they can transmit information and share resources. Embedded systems use different connection technologies in different occasions, such as home information network in family rooms, field bus in industrial automation, and mobile communication network in embedded systems such as mobile information devices. In addition, there are some special connection technologies used to connect embedded systems.
Fieldbus is a computer control technology developed in the mid-1980s following analog instrument control systems, centralized digital control systems and distributed control systems. It is one of the hot spots in the development of automation control technology today and is also commonly referred to as a computer local area network in the field of industrial automation.
Fieldbus is a network that connects field devices such as digital sensors, converters, industrial instruments and control actuators with industrial process control units, field operation stations, etc. It is characterized by full digitalization, decentralization, two-way transmission and multiple branches, and is the product of the development of industrial control networks to the field level.
Fieldbus is a low-bandwidth underlying control network, located at the bottom of production control and network structure, so it is also called the underlying network (Infranet). It is mainly used in production sites to achieve two-way, serial, multi-node digital communication between measurement and control devices.
Fieldbus control system (FCS) is a control system that uses fieldbus to connect various controllers and instrumentation equipment. This control system completely delegates control functions to the field, reducing installation costs and maintenance costs. In fact, FCS is an open, interoperable, and completely decentralized distributed control system.
The embedded field control system places a dedicated microprocessor into the traditional measurement and control instrument, so that it has digital computing and digital communication capabilities. It uses twisted pair, power line or optical fiber as a bus to connect multiple measurement and control instruments into a network, and according to the standard communication protocol, it realizes data transmission and information exchange between multiple microcomputerized measurement and control devices located on site and between field instruments and remote monitoring computers, forming various automatic control systems suitable for actual needs. In short, the fieldbus control system turns a single decentralized measurement and control device into a network node, and uses the fieldbus as a link to make these decentralized devices a network system that can communicate with each other and jointly complete automatic control tasks. With the help of fieldbus technology, the traditional single decentralized control device has become a whole that communicates with each other and works together.
The home information network is a local area network that connects personal computers, household appliances, water, electricity, gas meters, lighting equipment, network equipment, and security equipment within the home. Its main function is to centrally control the above-mentioned equipment and connect it to the Internet to share network resources and services. In addition, the home information network can also be extended to the entire house or even the entire community, becoming the foundation of smart residential communities and smart societies. In the home information network system, all home devices are intelligent, including household appliances, water, electricity, gas meters, and lighting equipment. They can communicate with each other and access the Internet through the home gateway. The implementation of the home information network provides people with a safer, more convenient, and more comfortable home environment. For example, when the owner goes out, the door automatically closes and locks, the monitoring system automatically turns on, and the owner can be automatically notified of abnormal situations at home. Various devices at home can be controlled anytime and anywhere, and instrument data can be automatically uploaded.
The family information network needs to solve two basic problems:
(1) How to connect household appliances, water, electricity, gas meters, lighting equipment, etc.
(2) How to achieve interoperability between these connected devices, that is, the devices on the home information network can automatically request services when needed, and the relevant devices can provide services or accept requests and process them. The home information network can adopt different topological structures, such as bus type, star structure, etc. The home information network can be further divided into several control subnets and data subnets. The control subnet is similar to the field bus, which is a network with low bandwidth and mainly used to send and receive control information. The data subnet has a higher bandwidth requirement, and the devices connected to it need to transmit a large amount of data information.
In recent years, with the rapid development of mobile phone communications and the rapid popularization of personal computers, a variety of portable computers, such as laptops, notebooks, handheld computers, etc., have increased rapidly, and data communication between fixed computers can no longer meet the needs. People hope to transmit and exchange data information anytime and anywhere, so data communication transmission media began to expand from wired to wireless, and wireless mobile data communication emerged. A wireless data communication network is a network system that transmits data through radio waves. It is developed on the basis of wired data communication and can realize data communication in a mobile state. Through the wireless data communication network, smart phones, PDAs and
Laptop computers can transmit data information to each other and access the Internet. Wireless data communication networks are divided into short-range wireless networks and wireless Internet. Short-range wireless networks mainly include 802.11, Bluetooth, IrDA and HomeRF. Wireless Internet or mobile Internet mainly uses two wireless connection technologies: one is mobile wireless access technology, such as GSM, GPRS, CDPD (Cellular Digital Packet Data), etc.; the other is fixed wireless access technology, including microwave, spread spectrum communication, satellite and wireless optical transmission.
With the rapid development of Internet and embedded technology, more and more information appliances, such as Web videophones, set-top boxes and embedded system products such as information appliances, require connection with the Internet to share the convenient, fast and ubiquitous information resources and services provided by the Internet, namely embedded Internet technology. Embedded Internet technology has broad application prospects in the fields of intelligent transportation, housekeeping systems, home automation, industrial automation, POS and e-commerce.
1. Embedded Internet access method
The TCP/IP protocol stack and related software are integrated on the embedded device. Such a device can be used as a node of the Internet, assigned an IP address, and directly connected to the Internet. The characteristics of this access method are:
2. Embedded TCP/IP protocol stack
The functions performed by the embedded TCP/IP protocol stack are the same as those of the complete TCP/IP protocol stack. However, due to the resource limitations of the embedded system, some indicators and interfaces of the embedded protocol stack may be different from those of the ordinary protocol stack.
(1) The calling interface of the embedded protocol stack is different from that of the general protocol stack. The socket interface of the general protocol stack is standard and has good compatibility with application software. However, the code overhead, processing and storage overhead of implementing the standardized interface are huge. Therefore, when most manufacturers transplant the standard protocol stack interface to the embedded system, they make modifications and simplifications to varying degrees and establish a highly efficient dedicated protocol stack. The API they provide may not be completely consistent with the API of the general protocol stack.
(2) Customizability of embedded protocol stacks. Most embedded protocol stacks are modular. If the memory space is limited, they can be dynamically installed when needed. They also omit several non-essential parts for embedded systems, such as interface forwarding and a full set of Internet service tools.
(3) Platform compatibility of embedded protocol stacks. Generally, protocol stacks are closely integrated with operating systems, and most protocol stacks are implemented in the operating system kernel. The implementation of protocol stacks depends on the services provided by the operating system, and its portability is poor. The implementation of embedded protocol stacks is generally not very dependent on the operating system, and is easy to port. Many commercial embedded protocol stacks support multiple operating system platforms.
(4) High efficiency of embedded protocol stack. The implementation of embedded protocol stack usually takes up less space, requires smaller data memory, and has high code efficiency, thus reducing the requirements for processor performance.
With the development of embedded technology, embedded databases are gradually being applied. In essence, embedded databases are developed from general databases and run on various embedded devices or mobile devices. They are more advantageous in embedded systems. However, due to the constraints of the application environment of the embedded system itself, embedded databases have different characteristics from general databases.
Usually, an embedded database management system is a database management system used on embedded devices. Since embedded database management systems are mostly used in mobile information devices, such as handheld computers, PDAs, vehicle-mounted devices and other mobile communication devices, and are rarely used in fixed embedded devices, embedded databases are also called mobile databases or embedded mobile databases. Their main function is to solve data management problems in mobile computing environments. Mobile databases are distributed in mobile computing environments.
Distributed database.
The introduction of database technology in embedded systems is mainly due to the following disadvantages of developing information management applications directly on embedded operating systems or bare metal:
(1) All applications have to repeat data management work, which increases development difficulty and cost.
(2) Data sharing between applications is poor.
(3) The application software has poor independence and portability, and low reusability.
Introducing a database management system into an embedded system can solve the above problems to a large extent and improve the development efficiency and portability of the application system.
An embedded database system is a comprehensive system that includes an embedded database management system and spans mobile communication devices, workstations or desktops, and data servers. This feature of the system and the system's usage environment have a great impact on the embedded database management system and directly affect the structure of the embedded database management system. The characteristics of its usage environment can be simply summarized as follows:
(1) The device is mobile at any time. Embedded databases are mainly used on mobile information devices, and the location of the device often moves with the user.
(2) Frequent network disconnection: The location of a mobile device or mobile terminal often changes during use, and is also affected by factors such as usage, power supply, wireless communication and network conditions. Therefore, the network connection is generally not maintained continuously, but is often disconnected and connected intermittently, actively or passively.
(3) Diversified network conditions. Due to the frequent changes in the location of mobile information devices, mobile information devices may connect to data servers through different network systems at different times. These networks may differ in terms of network bandwidth, communication cost, network delay, service quality, etc.
(4) Asymmetric communication capabilities: Due to the resource limitations of mobile devices, the network communication capabilities between mobile devices and servers are asymmetric. The sending capabilities of mobile devices are very limited, resulting in a large difference between the downlink communication bandwidth from the data server to the mobile device and the uplink bandwidth from the mobile device to the data server.
A complete embedded database management system consists of several subsystems, including the main database management system, synchronization server, embedded database management system, connection network, etc., as shown in Figure 12-6.
(1) Embedded database management system. An embedded database management system is a single-user database management system with independent functions. It can run independently of the synchronization server and the main database management system to manage the data in the embedded system. It can also connect to the main server through the synchronization server to operate the data in the main database. It can also synchronize data in a variety of ways.
(2) Synchronization server. The synchronization server is the connection hub between the embedded database and the main database, ensuring the consistency of data in the embedded database and the main database.
(3) Data server. The main database and database management system of the data server can adopt large-scale general database systems such as Oracle or Sybase.
(4) Network connection. The main database server and the synchronization server are generally connected through a high-bandwidth, low-latency fixed network. The connection between the mobile device and the synchronization server can be a wireless LAN, infrared connection, universal serial line or public network, etc., depending on the specific situation of the device.
1. Key points of embedded mobile database in application
In practical applications, embedded mobile databases must solve problems such as data consistency (replication), efficient transaction processing, and data security.
(1) Data consistency. A notable feature of embedded mobile databases is that the connection between mobile data terminals and the synchronization server is a weak connection, that is, low bandwidth, long latency, instability, and frequent disconnection. In order to support users' operations on the database in a weak environment, optimistic replication (Optimistic Replication or Lazy Replication) is now widely used to allow users to operate on the data copy in the local cache. After the network is reconnected, data modification information is exchanged with the database server or other mobile data terminals, and data consistency is restored through conflict detection and coordination.
(2) Efficient transaction processing. Mobile transaction processing must be performed in a mobile environment with frequent and predictable disconnections. In order to ensure the smooth completion of active transactions, new transaction management strategies and algorithms must be designed and implemented. The priority of transaction processing is determined based on the network connection status, and transaction requests with high network connection speed are given priority;
Determine whether the transaction is migrated based on the operation time, that is, long-term transaction operations will be migrated to the server for execution, without the need to ensure that the network is always unobstructed; determine whether the transaction is uploaded for execution or downloaded and then uploaded based on the amount of data; a complete logging strategy; during the transaction processing process, use the server discovery mechanism or the client declaration mechanism for network disconnection processing; real-time update of user location attributes during transaction movement (such as location-related queries).
(3) Data security. Embedded devices in many application fields are key devices for data management or processing in the system, so the database system on the embedded device has strict control over access rights. At the same time, many embedded devices have high mobility, portability and non-fixed working environment, which also brings potential unsafe factors. In addition, some data are very private, so the security of personal data needs to be fully guaranteed in terms of preventing collision, magnetic field interference, loss, theft, etc. The main measures to ensure data security are: authenticating mobile terminals to prevent fraudulent access by illegal terminals; encrypting wireless communications to prevent data information leakage; encrypting and storing downloaded data copies to prevent data leakage after the mobile terminal is physically lost.
2. Characteristics of mobile database management systems
The computing environment of mobile DBMS is an extension of traditional distributed DBMS. It can be regarded as a distributed system in which clients are dynamically connected to fixed server nodes. Therefore, the database management system in the mobile computing environment is a dynamic distributed database management system. Since the embedded mobile database management system is applied on the embedded operating system in the mobile computing environment, it has its own characteristics and functional requirements:
(1) Micro-kernel structure, which facilitates the realization of embedded functions. Considering the limited resources of embedded devices, embedded mobile DBMS should be implemented using miniaturization technology, and its system structure should be tightened to meet the needs of embedded applications while meeting the application requirements.
(2) Support for standard SQL. Embedded mobile DBMS should be able to provide support for standard SQL. It should support a subset of the SQL92 standard, data query (join query, subquery, sorting, grouping, etc.), insert, update, delete and other standard SQL statements to fully meet the needs of embedded application development.
(3) Transaction management function. The embedded mobile DBMS should have transaction processing functions, automatically maintain transaction integrity, atomicity and other characteristics, and support entity integrity and referential integrity.
(4) Perfect data synchronization mechanism. Data synchronization is the most important feature of embedded databases. Through data replication, changes in the embedded database or the main database can be applied to the other party to ensure data consistency. The data synchronization mechanism of the embedded mobile database management system should have the following characteristics:
(5) Support multiple connection protocols. The embedded mobile DBMS should support multiple communication connection protocols. It can connect to embedded devices and database servers through serial communication, TCP/IP, infrared transmission, Bluetooth and other connection methods.
(6) Complete embedded database management functions. The embedded mobile DBMS should have an automatic recovery function, which basically requires no human intervention for embedded database management and can provide data backup and recovery to ensure the security and reliability of user data.
(7) Platform independence and support for multiple embedded operating systems. The embedded mobile DBMS should be able to support multiple popular embedded operating systems such as Windows CE and Palm OS, so that the embedded mobile database management system is not restricted by mobile terminals.
(8) Zero management feature. The embedded database has an automatic recovery function, which allows embedded database management without manual intervention and provides data backup and synchronization.
In addition, an ideal state is that users can use only one mobile terminal (such as a mobile phone) to perform data operations and management on all mobile databases related to it. This requires the front-end system to be universal and the interface of the mobile database to have a unified and standardized standard. The front-end management system automatically generates a unified transaction processing command when processing data and submits it to the currently connected data server for execution. This effectively enhances the universality of the embedded mobile database management system and expands the application prospects of the embedded mobile database.
In short, in embedded mobile database management systems, many issues that do not need to be considered in traditional computing environments need to be considered, such as support for disconnected operations, support for cross-regional transactions, support for location-related queries, special considerations for query optimization, and considerations for improving the utilization of limited resources and system efficiency. In order to effectively solve the above problems, technologies such as replication and caching technology, mobile transaction processing, data broadcasting technology, mobile query processing and query optimization, location-related data processing and query technology, mobile information publishing technology, and mobile Agent are still being developed and improved, which will further promote the development of embedded mobile database management systems.
Simply put, a real-time system can be seen as a system that can respond to external events in a timely manner. The most important feature of this system is timeliness, that is, real-time. The correctness of a real-time system depends not only on the logical results of the system calculation, but also on the time when these results are generated.
At present, most real-time systems are embedded, and embedded systems in actual operation also have real-time requirements. Therefore, among the many types of embedded operating systems, real-time embedded operating systems are the most representative type. They integrate the characteristics of almost all types of embedded operating systems. Therefore, this section mainly takes the characteristics and concepts of real-time embedded operating systems as the main line, and comprehensively introduces the basic concepts and characteristics, basic architecture, kernel services, kernel objects and kernel services of embedded operating systems.
In the real world, not all embedded systems have real-time characteristics, and not all real-time systems are necessarily embedded. However, these two systems are not mutually exclusive. Systems that have both characteristics are called real-time embedded systems. The relationship between them is shown in Figure 12-7.
(1) Logical (or functional) correctness means that the system's processing of external events can produce correct results.
(2) Time accuracy means that the system's processing of external events must be completed within a predetermined period.
(3) Deadline or time limit, dead limit, or deadline refers to the latest time limit by which the system must process external events. Missing this limit may have serious consequences. Usually, the calculation must be completed before the deadline.
(4) A real-time system is a system that satisfies both functional correctness and timing correctness, both of which are equally important. In other words, a real-time system has time constraints and is time-driven. However, in some systems, timing correctness may be sacrificed in order to ensure functional correctness.
Real-time systems can usually be divided into the following categories based on the strength of their real-time nature, that is, the time it takes for the system to respond to external events:
(1) A strong real-time system has a very short response time, usually in milliseconds or microseconds.
(2) For general real-time systems, the system response time is lower than that required by strong real-time systems, usually in seconds.
(3) Weak real-time systems, whose system response time can be longer and may vary with the severity of the system load.
Depending on the tolerance for missing deadlines or the severity of the consequences, real-time systems can be divided into soft real-time systems and hard real-time systems.
(1) A hard real-time system is a real-time system that must meet the requirement of near-zero deadlines for its flexibility.
Otherwise, there will be catastrophic consequences, and the processing results obtained after the time limit will either be of zero uselessness or highly depreciated.
(2) Soft real-time systems refer to real-time systems that must meet deadline requirements but have a certain degree of flexibility. The deadline can include variable tolerance levels, average deadlines, or even statistical distributions of response times with varying degrees of acceptability. In a soft real-time system, deadline misses usually do not lead to serious consequences such as system failure. Table 12-2 compares soft real-time and hard real-time systems.
By comparison, we can see that since missing a deadline has no decisive impact on the operation of a soft real-time system, a soft real-time system does not need to predict whether there may be a pending deadline miss. Instead, a soft real-time system can start a recovery process after detecting a deadline miss.
In real-time systems, the start time of a task is as important as the deadline or completion time. The lack of required resources, such as CPU and memory, may hinder the start of task execution and directly lead to missing the task's completion deadline. Therefore, the deadline problem has evolved into a resource scheduling problem.
This has a crucial impact on both scheduling algorithms and task design.
The so-called embedded operating system refers to an operating system that runs on an embedded computer system and supports embedded applications. It is a collection of software used to control and manage hardware and software resources in an embedded system and provide system services. The embedded operating system is an important part of embedded software. Its emergence has improved the efficiency of embedded software development, improved the portability of application software, and strongly promoted the development of embedded systems.
1. Characteristics of embedded operating systems
Compared with general operating systems, embedded operating systems have the following main features:
(1) Miniaturization: The operating platform of an embedded operating system is not a general-purpose computer, but an embedded computer system. Such systems generally do not have large-capacity memory and almost no external memory. Therefore, the embedded operating system must be small to occupy as few system resources as possible. In order to improve the execution speed and reliability of the system, the software in the embedded system is generally solidified in the memory chip rather than stored in a carrier such as a disk.
(2) High code quality: In most applications, storage space is still a valuable resource, which requires that the program code be of high quality and as concise as possible.
(3) Specialization: The hardware platforms of embedded systems are diverse, and the processors are updated quickly. Each is specially designed for different application fields. Therefore, the embedded operating system must have good adaptability and portability, and support multiple development platforms.
(4) Strong real-time performance: Embedded systems are widely used in process control, data acquisition, communication, multimedia information processing and other situations that require real-time response. Therefore, real-time performance has become another feature of embedded operating systems.
(5) Customizable and configurable: The diversity of applications requires that the embedded operating system has strong adaptability and can be flexibly configured and reasonably customized according to the characteristics and specific requirements of the application to meet the requirements of miniaturization and specialization.
2. Classification of embedded operating systems
There are many types of embedded operating systems, which can be classified from different perspectives. From the form of obtaining embedded operating systems, they can be divided into two categories: commercial and free:
(1) Commercial. Commercial embedded operating systems are generally stable and reliable, with complete technical support, complete development tools and after-sales service. Examples include WindRiver's VxWorks and pSOS and Palm's Palm OS. However, they are expensive and users usually cannot obtain the source code of the system.
(2) Free. The advantage of free embedded operating systems is the price. In addition, application system developers can obtain system source code, which brings convenience to development. However, free operating systems have simple functions, poor technical support, and poor system stability. Typical representative systems include embedded Linux, uC/OS, etc. From the perspective of real-time performance, embedded operating systems can be divided into real-time embedded operating systems and non-real-time embedded operating systems.
(1) Real-time embedded operating system (RTEOS). A real-time embedded operating system supports real-time system operation. Its primary task is to schedule all available resources to meet the real-time deadline for responding to external events, and secondly, to improve the efficiency of the system. Real-time embedded operating systems are mainly used in control, communication and other fields. Currently, most commercial embedded operating systems are real-time operating systems.
(2) Non-real-time embedded operating systems. This type of operating system does not pay special attention to the response time limit of a single task. Its average performance, system efficiency and resource utilization are generally high. It is suitable for consumer electronic products with less strict real-time requirements, such as personal digital assistants, set-top boxes, etc.
Overall, the real-time performance of an embedded system is determined by hardware, real-time operating system and application programs, among which the performance of the embedded real-time operating system kernel plays a key role. Generally, there are two types of real-time embedded operating systems: real-time kernel-type RTEOS and general-purpose RTEOS.
Real-time kernel-based RTEOS: In this type of operating system, the driver is traditionally embedded in the kernel, and the applications and middleware are implemented on standard application programming interfaces (APIs, Application Programming Interfaces).
Real-time general-purpose RTEOS: In this type of operating system, the driver is not deeply embedded in the kernel, but is implemented on top of the kernel and contains only a few necessary drivers. Applications and middleware can be implemented directly on top of the driver without having to be implemented on standard APIs. The difference between them is shown in Figure 12-8.
There are many similarities in the functions between real-time embedded operating systems and general-purpose operating systems. For example, they both support multitasking, support software and hardware resource management, and provide basic operating system services for applications.
1. Key features of embedded real-time operating systems
Compared with general-purpose operating systems, real-time embedded operating systems have many functional features. The key features that are unique to real-time embedded operating systems and different from general-purpose operating systems are mainly:
2. Real-time performance indicators of embedded real-time operating systems When evaluating the performance of real-time operating system design, the time performance index is
The time performance index is the most important performance index. The commonly used time performance indicators are as follows:
(1) Task switching time: refers to the time required for the CPU control to be transferred from a running task to another ready task, including the time spent on saving and restoring the task context and the scheduling time for selecting the next task to be run when switching tasks. This indicator is related to the number of registers and system structure of the microprocessor. The same operating system may take different times when running on different microprocessors. The timing diagram corresponding to the task switching time is shown in Figure 12-9.
(2) Time indicators related to interrupt processing. The corresponding interrupt timing diagram is shown in Figure 12-10
Interrupt delay time refers to the time from when an interrupt occurs to when the system is notified of the interrupt, which is mainly affected by the system's maximum interrupt shutdown time.
The longer the interrupt is disabled, the longer the interrupt delay will be;
Interrupt processing execution time, which is determined by the specific application;
Interrupt response time refers to the time from the occurrence of an interrupt to the start of execution of the user interrupt service routine;
Interrupt recovery time refers to the time between the end of the user interrupt service routine and the return to the interrupted code;
The maximum interrupt-disable time includes two aspects: one is the maximum kernel interrupt-disable time, that is, the kernel turns off interrupts when executing critical section code; the other is the application interrupt-disable time, and the maximum interrupt-disable time is the maximum value of these two interrupt-disable times; the task response time refers to the time from the interrupt corresponding to the task to the time when the task actually starts running;
For preemptive scheduling, the time for interrupt recovery must be added to the time for task switching and restoring the new task context.
between.
(3) System response time: refers to the time from when the system issues a processing request to when the system responds, that is, the scheduling delay. The size of this time is mainly determined by the kernel task scheduling algorithm. In summary, the typical performance indicator calculation method of the preemptible real-time kernel is shown in Table 12-3.
According to incomplete statistics, there are hundreds of embedded operating systems in the world. Among them, there are more than a dozen most commonly used ones. These operating systems have high popularity and a large user base in their respective application fields. Table 12-4 selects some common embedded operating systems in the industry for comparison.
The main tasks of embedded system design are to define the functions of the system, determine the system architecture, and map the functions to the system implementation architecture. Here, the system architecture includes both the software system architecture and the hardware system architecture. An architecture can be mapped to a variety of different physical implementations, each of which represents different trade-offs, while also meeting certain design indicators and optimizing other design indicators at the same time.
The design method of embedded system is different from the general hardware design and software development method. It adopts the method of hardware and software co-design. The development process involves not only the knowledge in the software field, but also the comprehensive knowledge in the hardware field, and even the knowledge in mechanical field. It requires the designer to be familiar with and be able to use various technologies in these fields freely in order to optimize the designed system.
Although the design of embedded system application software varies with the application field, the analysis and design methods of embedded systems also follow the general principles of software engineering, and many mature analysis and design methods can be applied in the embedded field. The development process of embedded systems also includes several basic stages: requirements analysis, system design, implementation and testing, and each stage has its own unique characteristics and focus.
This section mainly introduces the technology and methods of embedded system development and design, and analyzes the methods of application software design and the main problems faced in the design process from the perspective of embedded system applications and computing models. Finally, the related issues of software transplantation in the embedded field are discussed.
Before designing an embedded system, the characteristics of the embedded system design itself and some major technical indicators for measuring the embedded system design should be clarified.
1. Characteristics of embedded system design
Compared with the usual system design, embedded system design has the following characteristics:
2. Technical indicators of embedded systems
Common indicators for embedded system design are:
(1) NRE cost (non-recurring engineering cost): the one-time monetary cost required to design the system. That is, once the design is completed, no additional design fees are required to manufacture any number of products.
(2) Unit cost: the monetary cost required to produce a single product, excluding NRE costs.
(3) Size: refers to the space occupied by the system. For software, it is generally measured in bytes; for hardware, it is measured in the number of logic gates or transistors.
(4) Performance: The time required for the system to complete a specified task is the most commonly used design indicator during design. There are two main ways to measure it: response time, which is the time between the start of execution and the end of the task. The other is completion volume, which is the amount of tasks completed per unit time.
(5) Power: The power consumed by the system, which determines the battery life or the heat dissipation requirements of the circuit.
(6) Flexibility: The ability to change system functionality without increasing NRE costs.
(7) Prototype building time: The time required to build an operational version of the system. The system prototype may be larger and more expensive than the final product, but it can verify the purpose and correctness of the system and improve the system's functionality.
(8) Time to market: The time from system development to when it can be sold to consumers. The most important influencing factors include design time, manufacturing time and testing time.
(9) Maintainability: The ease with which a system can be modified after it is released or marketed, especially by people other than the original developers.
(10) Correctness: The system functions are implemented correctly. The system functions can be checked during the entire design process, and test circuits can be inserted to verify whether they are correct.
(11) Safety: The probability that the system will not cause harm. Various design indicators are generally in competition with each other. Improving one indicator often leads to the deterioration of other indicators. In order to best meet the design optimization, designers must understand various software and hardware implementation technologies and be able to transfer from one technology to another in order to find the best solution under specific constraints.
3. Design challenges of embedded systems
The challenges faced by embedded system design are as follows.
(1) How much hardware is needed: Designers have a strong control over the computing power used to solve the problem. They can choose not only which processor to use, but also the amount of memory, the peripherals to be used, etc. Because the design must not only meet performance requirements but also be constrained by manufacturing costs, the choice of hardware is very important. Too little hardware will not meet the functional and performance requirements, while too much hardware will make the product too expensive.
(2) How to meet the time limit: It is not advisable to use the method of increasing the processor speed to speed up the program to solve the time constraint, because this will increase the price of the system. At the same time, increasing the processor clock frequency sometimes does not increase the execution speed, because the speed of the program may be limited by the storage system.
(3) How to reduce system power consumption: For battery-powered systems, power consumption is a very sensitive issue. For non-battery-powered systems, high power means high heat dissipation. One way to reduce system power consumption is to reduce its computing speed, but simply reducing the computing speed will obviously lead to unsatisfactory performance. Therefore, it is necessary to carefully design the system to meet performance constraints while reducing power consumption.
(4) How to ensure the system's upgradability: The system's hardware platform may have been used for several generations, or different levels of products of the same generation may be used. These only require some simple changes. Designers must change the system's characteristics by changing the software and design a machine that can provide the performance of software that has not yet been developed.
(5) How to ensure system reliability: Reliability is an important indicator when selling products. It is a reasonable requirement of consumers that products can work well. Reliability is particularly important in some systems, such as safety control systems.
(6) Complexity of testing: Testing an embedded system is much more difficult than just inputting some data, so the entire machine has to be run to generate the correct data. The time when the data is generated is very important, that is, the embedded system cannot be tested without leaving the entire environment in which the embedded system works.
(7) Limited visibility and controllability: Embedded systems usually do not have display devices and keyboards, which makes it difficult for developers to understand what is happening inside the system and respond to the system's actions. Sometimes they have to observe the signals of the microprocessor to understand. In real-time systems, it is generally impossible to shut down the system for observation.
(8) Limited development environment: The development environment of embedded systems, such as development software and hardware tools, is usually more limited than the available environment on general-purpose computers or workstations. Therefore, only cross-development can be adopted, which has a great impact on the development progress.
Similar to the development of general systems, the development of embedded systems can also adopt common development models in software engineering, mainly including waterfall model, spiral model, step-by-step refinement model and hierarchical model.
1. Common development models
The design process is a series of steps that should be followed during system design, some of which can be completed by automated tools, while others can only be completed manually. In the field of embedded systems, there are several commonly used development process models.
(1) Waterfall model. The waterfall model consists of five main stages: the requirements analysis stage determines the basic characteristics of the target system; the system structure design stage decomposes the system's functions into major structures; the coding stage is mainly for program writing and debugging; the testing stage detects errors; and the last one is the maintenance stage, which is mainly responsible for modifying the code to adapt to environmental changes, correcting errors, and upgrading. The work and information in each stage always flow in one direction from high-level abstraction to more detailed design steps. It is an ideal top-down design model.
(2) Spiral model. The spiral model assumes that multiple versions of the system are to be built. The early version is a simple test model to help designers build intuition about the system and accumulate experience in developing the system. As the design progresses, a more complex system will be created. At each level of design, the designer will go through three stages: requirements analysis, structural design, and testing. In the later stages, when more complex system versions are constructed, there will be more work at each stage and the design spiral will need to be expanded. This step-by-step refinement method allows designers to deepen their understanding of the system being developed through a series of design cycles. The first cycle at the top of the spiral is very small and short, while the last cycle at the bottom of the spiral adds details to the early cycles of the spiral model. The spiral model is more realistic than the waterfall model.
(3) Stepwise refinement model. The stepwise refinement model is a system that is built multiple times, with the first system used as a prototype and each system being refined one by one. This approach makes sense when the designer is not very familiar with the application domain of the system being built. By building several increasingly complex systems, the system is refined, allowing the designer to test the architecture and design techniques. In addition, various iterative techniques can be completed only partially until the system is finally completed.
(4) Hierarchical model. Many embedded systems are composed of more small designs. A complete system may require various software components and hardware components. These components may be composed of smaller components that need to be designed. Therefore, from the initial complete system design to the design of individual components, the design process changes with the change of the abstraction level of the system. From the overall design at the highest abstraction level to the detailed design at the middle abstraction level, and then to the design of each specific module, they are all carried out layer by layer. Each process may be undertaken by a single designer or design team. Each team relies on the results of other teams. Each team obtains requirements from the upper team, and the upper team relies on the quality and performance of each group design. Moreover, each implementation stage of the process is a complete process from specification to testing.
2. Design methods for embedded systems
A good embedded system design methodology is important because:
(1) A good design method enables designers to clearly understand the progress of their work, thus ensuring that no work is missed.
(2) Allow the use of computer-aided tools to assist designers in their work and divide the entire process into several controllable steps.
(3) Good design methods facilitate communication among members of the design team. By defining a comprehensive design process, each member of the team can have a good understanding of the work they are supposed to do and the goals to be achieved when completing their assigned tasks.
The development process of embedded system software can be divided into several stages: project planning, feasibility analysis, requirements analysis, outline design, detailed design, program establishment, downloading, debugging, curing, testing and operation.
The project planning, feasibility analysis, requirements analysis, outline design and detailed design stages are basically the same as the general software development process, and can all be carried out according to software engineering methods, such as prototyping methods and structured methods.
Since the running and development environments of embedded software are different, the development work is cross-developed, so this point must be taken into account at every step. The work in the program establishment phase is carried out according to the documents generated in the detailed design phase. The work in this phase mainly involves several sub-processes such as source code writing, compilation, and linking. These tasks are all carried out on the host machine and do not require the target machine. After the executable file of the application is generated, the cross-development environment must be used for debugging. According to the actual situation, you can choose
Use one of the several debugging methods available or an effective combination of them. Embedded system design is different from traditional software design, as shown in Figure 12-11. It often includes hardware design and software design, where front-end activities, such as specifications and system architecture, need to consider both hardware and software aspects.
Similarly, back-end design, such as system integration and testing, must consider the entire system. In the middle stage, the development of software and hardware components is independent of each other, and most hardware and software work can be carried out relatively independently. Finally, the debugged and correct executable program must be fixed to the target machine. Depending on the configuration of the embedded system hardware, there are several ways to fix it. It can be fixed in memories such as EPROM and FLASH, or in electronic devices such as DOC and DOM.
Usually, some special programmers are needed to do this.
Since embedded systems have higher requirements for security and reliability than general-purpose computer systems, higher code coverage is required when white-box testing embedded systems. At each stage of the system development process, system confirmation and performance evaluation, security evaluation and risk assessment must be performed, and the system implementation must be tested and verified.
The development of embedded systems is a comprehensive development of software and hardware, which is very different from the development of general systems. On the one hand, each embedded system is a combination of software and hardware; on the other hand, once the embedded system is developed, the software is solidified into the product along with the hardware, which has strong specificity. Under the influence of these characteristics, there must be an engineering methodology different from the general software development process to support the development process of embedded systems. At the same time, these characteristics also determine the unique core technology used in the development of embedded systems.
Generally speaking, in the field of embedded development, there are three core technologies: processor technology, IC technology, and design/verification technology.
1. Processor Technology
Processor technology is related to the computing engine structure that implements system functions. Many non-programmable digital systems can also be regarded as processors. The difference between these processors lies in the degree of specialization for specific functions, which makes their design indicators different from other processors.
(1) General-purpose processors. This type of processor can be used for different types of applications. An important feature is the storage of programs. Since the designer does not know what operations the processor will run, it is impossible to create programs using digital circuits. Another feature is the universal data path. In order to handle various different calculations, the data path is universal. The data path generally has a large number of registers and one or more general-purpose arithmetic logic units. The designer only needs to program the processor's memory to perform the required functions, that is, design the relevant software.
Using general-purpose processors in embedded systems has some design advantages. Time to market and NRE costs are lower because designers only need to write programs without doing any digital design. It is highly flexible and functional changes can be made by modifying the program. Compared with designing processors by yourself, the unit cost is lower when the quantity is small.
Of course, this approach also has some design indicator defects. The unit cost is relatively high when the quantity is large, because when the quantity is large, the NRE cost of self-design is amortized, which can reduce the unit cost. At the same time, for some applications, the performance may be very poor. Due to the inclusion of unnecessary processor hardware, the system size and power consumption may become larger.
(2) Single-purpose processors. Single-purpose processors are digital circuits designed to execute specific programs. They also refer to coprocessors, accelerators, peripherals, etc. For example, the JPEG codec executes a single program to compress or decompress video information. Embedded system designers can create single-purpose processors by designing specific digital circuits. Designers can also use pre-designed commercial single-purpose processors.
There are some advantages and disadvantages in the use of single-purpose processors in embedded systems. These advantages and disadvantages are basically opposite to general-purpose processors. The performance may be better, the size and power may be smaller, the unit cost may be lower when the quantity is large, but the design time and NRE cost may be higher, the flexibility is poor, the unit cost is higher when the quantity is small, and for some applications, the performance is not as good as that of general-purpose processors.
(3) Special-purpose processors. A special-purpose instruction set processor is a programmable processor that is optimized for a specific type of application. Such specific applications have common characteristics, such as embedded control, digital signal processing, etc. Using special-purpose processors in embedded systems can provide greater flexibility while ensuring good performance, power and size, but such processors still require expensive costs to build the processor itself and the compiler. Microcontrollers and digital signal processors are two widely used types of special-purpose processors. Digital signal processors are microprocessors that perform common operations on digital signals, while microcontrollers are microprocessors optimized for embedded control applications.
2. IC technology
The technology that implements the physical mapping process of the actual chip from the integrated circuit design description of the system is IC (Integrated Circuits) technology. Currently, the three types of implementation technologies in the semiconductor field, namely full customization, semi-customization and programmable technology, can all be applied to the hardware design of embedded systems.
(1) Full Custom/VLSI (Very Large Scale Integrated Circuits). In full custom IC technology, designers at all levels need to optimize the size, position, and connection of transistors according to the digital implementation of a specific embedded system to achieve the optimal performance of high chip area utilization, high speed, and low power consumption. The actual chip is produced in the manufacturing plant using masks. Full custom IC design is also often called VLSI. It has a high NRE cost and a long manufacturing time. It is suitable for large-scale or performance-critical applications.
(2) Semi-custom/ASIC (Application Specific Integrated Circuit). Semi-custom ASIC is a constraint-based design method, including gate array design method and standard cell design method. It is a semi-finished hardware with some universal unit components and component groups made on the chip. The designer only needs to consider the logical function of the circuit and the reasonable connection between the functional modules. This design method is flexible, convenient, cost-effective, shortens the design cycle, and improves the yield rate.
(3) Programmable/ASIC. All layers in programmable devices already exist. After the design is completed, the designed chip can be burned in the laboratory without the involvement of IC manufacturers, and the development cycle is significantly shortened. Programmable ASIC has a lower NRE cost, a higher unit cost, higher power consumption, and a slower speed.
3. Design/Verification Technology
The design technology of embedded systems mainly includes two categories: hardware design technology and software design technology. Among them, the technology in the field of hardware design mainly includes two aspects: chip-level design technology and circuit board-level design technology.
The core of chip-level design technology is compilation/synthesis, library/IP (Intellectual Property), and test/verification. Compilation/synthesis technology enables designers to describe the required functions in an abstract way and automatically analyze and insert implementation details. Library/IP technology uses pre-designed low-level abstraction implementations for high-level abstraction. Test/verification technology ensures that each level of function is correct and reduces the cost of repeated design between levels.
The core of software design technology is software language. Software language has experienced a development process from low-level language (machine language, assembly language) to high-level language (for example, structured design language, object-oriented design language), and its development is driven by many related technologies such as assembly technology, analysis technology, compilation/interpretation technology, etc. The level of software language has also gradually transitioned from implementation level, design level, and function level to requirement level language.
In the early days, as the concept of general-purpose processors gradually took shape, software technology developed rapidly, and the complexity of software began to increase. The technology and fields of software design and hardware design were completely separated. Design technology and tools have developed simultaneously in these two fields, which also allows behavioral descriptions to be performed at increasingly abstract levels to meet the needs of growing design complexity. This synchronous development now allows both fields to use the same timing model to describe behavior, so the two fields may soon be unified into one field again.
Since most embedded systems are real-time reactive systems, which have the characteristics of multi-task concurrency, strict time constraints and high reliability, people have proposed a variety of description languages and verification methodologies for the design and description of reactive systems. For example, temporal logic is used to characterize the properties of reactive systems and reason about the behavior of reactive systems, and model checking technology is used to verify the correctness of reactive system design. These technologies have gradually played an important role in the embedded development process.
There are many types of embedded system development environments, which can be roughly divided into the following categories:
(1) Development environment supporting embedded operating systems. There are many development environments in this category. For example, commercial embedded operating systems such as PalmOS, THOS, VxWorks, and Windows CE all have fully functional development environments supporting them.
(2) Development environment that matches the processor chip. This type of development environment is generally provided by the processor manufacturer. For example, EPSON has launched a toolkit specifically for developing embedded systems based on the S1C33 series microcontroller chips.
(3) Development environment that matches the specific application platform. This type of development environment is highly targeted, such as Qualcomm's Brew SDK.
(4) Other types of development environments. This type of development environment mainly refers to the more general development environments developed or customized by some embedded system vendors based on GNU open source tools. These tools can be obtained free of charge, support a wide range of processor types, and have complete functions, but are slightly inferior to professional commercial tools in terms of technical support.
As the functions of embedded systems become increasingly complex, it is becoming increasingly difficult to describe the behavior of these complex systems. Practice has proved that using computational models to describe and analyze systems is a method with engineering value.
This section introduces several commonly used computing models in the embedded field, and analyzes and explains related issues in embedded application design and development from the perspective of computing models. Computational models provide a set of methods to combine complex behaviors with simple objects, which can help designers understand and describe system behaviors. Commonly used computing models in embedded systems are as follows: timing computing model, communication process model, state machine model, data flow model, object-oriented model, and concurrent process model. These models are used in different application fields. For example, the state machine model is particularly suitable for describing control-based systems, and the data flow model can well describe data processing and conversion issues. The most widely used model is the concurrent process model.
1. State machine model
Finite-State Machine (FSM) is a basic state model that can describe the behavior of a system using a set of possible states. The system can only be in one of the states at any time. It can also describe the state transition determined by the input, and finally describe the operations that may occur in a certain state or during the state transition.
A finite state machine FSM is a six-tuple F<S，I，O，F，H，S0> , where S is a state set {s0, s1, …, sl}, I is the input set {I0, I1, …, Im}, O is the output set {o0, o1, …, on}, F is the next state function or transition function, mapping states and inputs to states (S×I→S), H is the output function, mapping states to outputs (S→O), and S0 is the initial state.
Figure 12-12 is a description of the state machine of the elevator control unit. In the initial "idle" state, up and down are set to 0, and open is set to 1. The state machine stays in the "idle" state until the requested floor is different from the current floor. If the requested floor is greater than the current floor, the state machine transfers to the "up" state and sets up to 1. If the requested floor is less than the current floor, the state machine transfers to the "down" state and sets down to 1. The state machine stays in the "down" or "up" state until the current floor is equal to the requested floor, and then the state transfers to the "open door" state and sets open to 1. Usually, the system has a timer, so when the state machine transfers to the "open door" state, the timer is also started, and the state machine stays in the "open door" state until the timer times out, and finally transfers to the "idle" state.
When FSM is used for embedded system design, the data types of its input and output are Boolean types, and the functions represent Boolean functions with Boolean operations. This model is sufficient for many pure control systems without data input or output. If data is to be processed, the FSM is expanded to a state machine with datapath (FSM with Datapath, FSMD). In addition, the state machine model can be further expanded to support hierarchical and concurrency. This model is called a hierarchical/concurrent FSM (HCFSM) model.
2. Data flow model
The data flow model is a model derived from the concurrent multi-task model. The model describes the behavior of the system as a set of nodes and edges, where nodes represent transformations and edges represent the flow of data from one node to another. Each node uses data from its input edge, performs transformations, and produces data on its output edge.
Each edge may or may not have data. The data that appears on the edge is called a token. When all the input edges of a node have at least one token, the node can be triggered. After the node is triggered, a token from each input edge will be used to transform the data of all the tokens used, and a token will be generated on the output edge. The triggering of the node is only determined by the appearance of the token.
Figure 12-13 shows the data flow model for calculating z=(a+b)×(cd). Currently, there are several commercial tools that support the expression of data flow models in graphical languages. These tools can automatically convert data flow models into concurrent multi-task models for implementation on microprocessors. The conversion method is to convert each node into a task and each edge into a channel. The implementation method of the concurrent multi-task model is to use a real-time operating system to map concurrent tasks.
Figure 12-14 is a synchronous data flow model. In this model, the number of tokens used and generated for each trigger is marked on each input edge and output edge of the node. The advantage of this model is that it does not need to be converted into a concurrent multi-task model during implementation. Instead, the nodes are scheduled in a static way to generate a sequential program model. This model can be expressed in a sequential program language (such as C language) and can be executed without a real-time operating system, so its execution efficiency is higher.
3. Concurrent Process Model
The concurrent process model is composed of a group of processes, each of which is a sequentially executed process, and the processes can be executed concurrently. The concurrent process model provides operations for creating, terminating, pausing, resuming, and connecting processes. Processes can communicate with each other and exchange data during execution. There are two ways to communicate between processes: shared variables and message passing. Semaphores, critical sections, monitors, and path expressions are used to synchronize the operations of concurrent processes.
Generally, a real-time system can be viewed as a system consisting of many concurrently executed processes, each of which has a time requirement. In this way, many embedded systems are more easily described by a set of concurrently executed tasks, because these systems are multi-tasking systems themselves, and the concurrent process model can naturally be implemented by the multi-tasking of the real-time operating system.
4. Object-oriented model
The traditional concurrent process model is designed around the concept of process. Process is an implementation-level concept and an indirect simulation of activities in the objective world. Therefore, it is extremely unnatural to use the process model to solve concurrent problems in the objective world, and it also makes concurrent programs difficult to design and understand.
The object-oriented model describes the activities in the objective world in a more direct way. There is potential concurrent execution capability in the model. After an object sends a message to another object, if it does not need or does not need the processing result of the message immediately, the former does not have to wait for the latter to process the message. The message sender and the message receiver can execute concurrently. Objects are not all in a passive service state. In addition to providing services by receiving messages, some of them can also have their own transaction processing.
An object can often handle multiple messages at the same time.
An object is an encapsulation of data and operations. Data is stored in the local variables of the object. The state of an object is represented by the values of all the local variables of the object at a certain moment. In a concurrent environment, the description of the concurrent state of the object must also be considered, because the concurrency control of the object is based on the concurrent state of the object. Combining concurrency with object-orientation can be summarized into two approaches:
(1) Introduce concurrency mechanisms into object-oriented models, fully utilize the object-oriented technology's ability to model the objective world and the important characteristics of object-oriented technology, and at the same time describe its potential concurrency capabilities to make it suitable for describing concurrent computing.
(2) Introducing object-oriented thinking into the traditional concurrency model. Object-oriented concurrency models can be divided into two types: implicit concurrency model and explicit concurrency model.
(1) Implicit concurrency model. This model is characterized by postponing concurrency design and taking object modeling as the basis for modeling. Before entering the running phase, objects are regarded as autonomous units, and the activities of various objects are regarded as specific tasks completed in an ideal concurrent manner. Just like each object has its own processor, this processor can provide an execution thread for the object. External events entering the system are regarded as a processing request, which is broadcast to some objects, and these objects then make further processing requests to other objects. In theory, corresponding to one request, any number of objects can perform the corresponding processing. In implementation, the scheduler ultimately determines the operation order of its objects, as shown in Figure 12-15.
(2) Explicit concurrency model. The characteristic of this model is that concurrency is considered first, and the concept of concurrency and the concept of object should be separated first. After the object is established, the process concept supported by the real-time operating system is used to represent concurrency, forming two abstract levels of objects and processes. That is, the system is first decomposed into quasi-concurrent processes as a start, and object-oriented technology is used inside each process. The interaction between objects is represented as nested function calls, and the integrity of the object is guaranteed by adding explicit synchronization mechanisms such as locks, monitors, and semaphores. This model places the process above the object, and there is no need to consider concurrency or object serialization in the object, as shown in Figure 12-16.
In the early days, the design method of real-time systems was mainly structured design methods. Systems using structured methods have great limitations in terms of reusability and modifiability. Object-oriented real-time system design methods obviously have obvious advantages in these issues. A more practical object-oriented design method is Nokia's OCTOPUS method, which is based on OMT and the Fusion Method. It proposes a method for processing the response time, time domain and concurrency of real-time systems, and specifically proposes processing for concurrency, synchronization, communication, interrupt processing, ASIC, hardware interface, end-to-end response time, etc. The OCTOPUS method combines the main stages of software development well, and the transition from specification to operation model is tight and natural, and it also supports incremental development. The OCTOPUS method is a typical design method that combines object-oriented technology and real-time systems. In addition, formal object-oriented development technology and modeling languages are gradually being applied in the initial stage of real-time system modeling.
Before designing, designers must know what to design. Requirements and specifications are often used to describe these two related but different steps in the design process. Requirements are informal descriptions of what users want, while specifications are more detailed, accurate, and consistent descriptions that can be used to create system architectures. Of course, both requirements and specifications are external representations that guide the system, not internal representations. There are two types of requirements: functional requirements and non-functional requirements. Functional requirements describe what the system must do, while non-functional requirements describe other properties of the system, such as physical size, price, power consumption, design time, reliability, etc.
Performing a requirements analysis for a large system is a complex and time-consuming task, but obtaining a small amount of information in a clearly formatted, concise format is a good start to understanding the system requirements. Table 12-5 is a requirements form that is filled out at the beginning of a project and can be used as a checklist when considering the basic characteristics of the system.
This requirement form is written based on the example of GPS (Global Position System, mobile map system). Mobile map system is a handheld device designed for users driving on highways or similar users. The device can obtain location information from GPS and display the current location and surrounding terrain map for the user. The content of the map changes as the location of the user and the device changes.
The most important document output of the requirements analysis phase is the system specification.
Specifications are technical documents that accurately reflect customer needs and must be followed during design. Specifications are very important in the software development process. System analysts accept user requirements and generate specifications for the target software system. Designers and coders design modules based on the specifications and eventually generate program code. Testers and acceptance personnel verify whether the final software meets the specifications. Specifications should be clear and unambiguous, otherwise the system built by the specifications may not meet actual requirements.
At present, the more popular method in the industry is to use UML for specification description. UML is a universal standard modeling language that can model any system with static structure and dynamic behavior. UML is applicable to different stages of system development, from requirement specification description to system completion testing. Figure 12-17 is an example of a state machine specification that shows an operation. Start and end are special states. The states in the state machine represent different conceptual operations.
In the requirements analysis phase, use cases are used to capture user requirements. Use case modeling is used to describe external roles that are interested in the system and their functional requirements for the system (use cases). The analysis phase is mainly concerned with the main concepts (such as abstractions, classes, and objects) and mechanisms in the problem domain. These classes and their relationships need to be identified and described using UML class diagrams. In the analysis phase, only the objects of the problem domain (real-world concepts) are modeled, without considering the classes that define the technical details of the software system (such as classes that handle issues such as user interfaces, databases, communications, and parallelism).
Currently, design tools for embedded systems can be divided into two categories: collaborative synthesis tools and collaborative simulation tools.
(1) Collaborative synthesis tools. Currently, the main collaborative synthesis tools used for embedded development include POLIS, COSYMA, and Chinook.
POLIS: POLIS is a software and hardware co-design framework for interactive embedded systems developed by UC-Berkeley. It is suitable for the design of small control systems, and the system description supports a language based on FSM (Finite State Machine). Since both software and hardware can be transparently obtained from the same CFSM description, the flexibility of the design space is also increased accordingly. It supports co-simulation using PTOLEMY and supports formal verification at both the description and implementation levels. The architecture support is limited, that is, the hardware CFSMs are surrounded by only one processor and do not support shared memory.
COSYMA: COSYMA is a platform developed by the German company IDA for exploring the synthesis process of hardware and software co-design. It has a simple description for software systems, supports automatic partitioning and co-processor synthesis, and can explore the design space during the synthesis period. System synthesis depends on hardware limitations and does not support concurrent modules, that is, only one thread can be executed at a time. The architecture is also limited and does not support formal verification. The success of the design depends on the partitioning and cost estimation techniques.
Chinook: Chinook is designed for control systems. The description of the entire system is provided as an input to Chinook. Its internal model is based on a hierarchical state-like model. It does not segment the code and provides a single simulation environment for the entire design. Chinook supports multiple system architectures, especially multi-processor architectures. It also supports descriptions of timing constraints. It can synthesize multiple interfaces, including software and hardware interfaces between systems, and can synthesize device drivers directly from timing diagrams to control communication between processors.
(2) Co-simulation tools. Co-simulation is a crucial aspect of embedded system design. After the entire system is designed, it is necessary to simulate different types of components under a unified framework. Co-simulation not only provides verification, but also provides users with performance information of each system, which helps to propose changes to the system in the early stages to avoid major losses. Currently, there are two main co-simulation tools.
PTOLEMY: The key idea of PTOLEMY is to mix object-oriented kernel computing models, which can be used to simulate a variety of systems and is widely used in various applications, but it is not suitable for system synthesis. Hardware simulation is also one of its functions. TSS: TSS (Tool for System Simulation) is a tool for simulating complex hardware. It is written in C language. The extraction of a single module can be controlled by the user, and modules can be easily added and deleted. However, it does not support hierarchical modules, and there is no mechanism for synchronizing the access of each processor to a shared data structure. Communication between modules is carried out through ports and buses. In addition, TSS supports the simulation of multi-core systems.
1. System architecture design
The main purpose of system architecture design is to describe how the system implements the functions defined in the specification. However, it is difficult to completely separate software and hardware when designing the system structure of an embedded system. The usual approach is to consider the system's software architecture first, and then consider its hardware implementation. The description of the system structure must meet both functional and non-functional requirements. Not only must the required functions be reflected, but also non-functional constraints such as cost, speed, and power consumption must be met. Starting from the functional elements in the original block diagram of the system, considering and refining them one by one, and converting the original block diagram into software and hardware system structures while considering non-functional constraints is a practical method. The following takes the architecture design of the GPS mobile map system as an example to illustrate.
(1) Original block diagram. As shown in Figure 12-18, this original block diagram is the main operation and data flow of the mobile map system.
(2) Software system architecture. As shown in Figure 12-19, the software system mainly consists of a user interface, a database search engine, and a data converter.
(3) Hardware system architecture. As shown in Figure 12-20, the hardware system is composed of a general-purpose microprocessor, memory, and I/O devices. This system uses two types of memory: general-purpose data and program memory and frame buffer memory for pixel display.
2. Hardware subsystem design
The development environment of embedded systems consists of four parts: target hardware platform, embedded operating system, programming language and development tools. The selection of processor and operating system should take more factors into consideration to avoid wrong decisions affecting the progress of the project.
(1) Selecting processor technology. The main challenge of embedded system design is how to optimize competing design indicators at the same time. Designers must choose between the advantages and disadvantages of various processor technologies and IC technologies. Generally speaking, processor technology is independent of IC technology, that is, any processor technology can be implemented using any IC technology, but the performance, NRE cost, power consumption, size and other indicators of the final device will vary greatly, as shown in Figure 12-21.
More general programmable technology provides greater flexibility, reduces NRE costs, and accelerates product prototyping and time to market. Customized technology can provide lower power consumption, better performance, smaller size, and low cost in mass production.
Usually, when a company wants to launch a product, such as a set-top box, home router, or general-purpose processor, it can first launch a semi-custom product to capture the market as quickly as possible, and then launch a fully customized product. It can also use more reliable old technology to implement the processor first, and then use new process technology to implement the next generation. Similarly, embedded system designers can use programmable devices to build prototypes to accelerate time to market, and then use customized devices for mass production. Based on these principles, designers can make reasonable choices about the processor technology and processors to be used. Generally, fully customized commercialized "general-purpose processor software" is an option that is applicable in most cases.
(2) Selection of general-purpose embedded processors. Choose a suitable general-purpose embedded processor based on user needs and project requirements. The following indicators should be considered when making the selection.
Processor speed. The performance of a processor depends on many factors: clock frequency, size of internal registers, whether instructions process all registers equally, etc. For many embedded system designs that require processors, the goal is not to select the fastest processor, but to select a processor and I/O subsystem that can complete the job. The performance of the processor meets the needs of the system and has a certain margin, but it does not have to be too high. Technical indicators. Currently, many embedded processors integrate the functions of peripheral devices, thereby reducing the number of chips and thus reducing the development cost of the entire system. The first thing developers consider is whether some of the hardware required by the system can be connected to the processor without too much combinational logic. The second is to consider some supporting chips for the processor, such as DMA controllers, memory managers, interrupt controllers, serial devices, clocks, etc. The developer's familiarity with the processor, that is, the project developer needs to make a trade-off between the cost of the processor itself and the development cost.
Whether the processor's I/O function meets the system's needs, that is, many processors provide built-in external devices to reduce the number of chips and reduce costs, and this solution should be considered as much as possible. The processor's related software support tools, that is, whether the processor has a complete embedded operating system, programming language and development tool support, etc.
Processor debugging, that is, whether the processor has integrated debugging functions, such as whether it supports JTAG, BDM and other debugging methods. The support credibility of the processor manufacturer. When choosing a processor in the product life cycle, the designer must confirm that it has sufficient supply, technical support, and low power consumption of the processor.
The largest and fastest growing market for embedded microprocessors is consumer electronics such as handheld devices, electronic notepads, PDAs, mobile phones, GPS navigators, and smart home appliances. The typical characteristics of the microprocessors selected for these products are high performance and low power consumption. Many CPU manufacturers have entered this field.
(3) Considerations for hardware design. First, divide the hardware into components or modules and draw a block diagram for connecting the components or modules. Second, refine each module and divide the system into more manageable small blocks that can be implemented separately. Usually, some functions of the system can be implemented by both software and hardware. There is no unified method to guide designers to decide on the allocation of functions between software and hardware, but they can make a trade-off between performance and cost based on the constraint list. When designing the interface between software and hardware, it requires the collaboration of hardware designers and software designers. A good interface design can ensure that the hardware is simple and easy to program. The following points should be noted during design.
In short, hardware designers should give software designers more and more detailed information to facilitate software design and development.
3. Software subsystem design
According to the specification document in the requirements analysis phase, determine the system calculation model and make a reasonable design for the software part.
(1) Choice of operating system. When choosing an embedded operating system, you need to consider many aspects:
Operating system functions. Choose an operating system product based on the operating system functions required by the project. Consider factors such as whether the system supports all or part of the operating system functions, whether it supports the file system and human-computer interface, whether it is a real-time system or a time-sharing system, and whether the system can be tailored.
Selection of supporting development tools. Some real-time operating systems (RTOS) only support the development tools of the system vendor. In other words, compilers, debuggers, etc. must also be obtained from the operating system vendor. Some operating systems are widely used and third-party tools are available, so there is a lot of room for choice. The ease of porting the operating system. The porting of the operating system to the hardware is an important issue. It is a key factor in whether the entire system can be completed on schedule. Therefore, it is necessary to choose operating systems with high portability to avoid the difficulties caused by the difficulty of porting the operating system to the hardware and accelerate the development progress of the system. What is the memory requirement of the operating system. Balance whether additional RAM or EEPROM is needed to meet the operating system's larger memory requirements. Some operating systems have target-related memory requirements. For example, Tornado/VxWorks allows developers to allocate the required resources according to application requirements instead of allocating resources to the operating system. From embedded designs that require a few kilobytes of storage to complex high-end real-time applications that require more operating system functions, developers can choose up to 80 different configurations.
Operating system additional software package. Does it contain the required software components, such as network protocol stack, file system, various common peripheral drivers, etc.? How is the real-time performance of the operating system? Real-time performance is divided into soft real-time and hard real-time. Some embedded operating systems can only provide soft real-time performance, such as Microsoft Windows CE 2.0, which is a 32-bit, Windows-compatible, micro-kernel, scalable real-time operating system that can meet the needs of most embedded and non-embedded applications. But the real-time performance is not strong enough, and it belongs to the category of soft real-time embedded operating system.
Operating system. How flexible is the operating system? Is the operating system customizable, that is, can the system functions be customized according to actual needs? Some operating systems are highly customizable, such as embedded Linux, Tornado/VxWorks, etc.
(2) Choice of programming language. When choosing a programming language, you also need to consider many aspects:
Versatility. With the continuous development of microprocessor technology, its functions are becoming more and more specialized and its types are increasing. However, different types of microprocessors have their own dedicated assembly languages. This sets a huge obstacle for system developers, making system programming more difficult and software reuse impossible. High-level languages are generally less related to the hardware structure of specific machines. The more popular high-level languages have good support for most microprocessors and are more versatile.
Portability. Since assembly language is closely related to specific microprocessors, a program designed for a certain microprocessor cannot be directly ported to another different type of microprocessor for use, so portability is poor. High-level languages are common to all microprocessors, so programs can run on different microprocessors and have better portability. This is the basis for achieving software reuse. Execution efficiency. Generally speaking, the higher the level of the language, the larger its compiler and overhead, and the larger and slower the application. However, relying solely on low-level languages, such as assembly language, to develop applications will bring about complex programming and a long development cycle. Therefore, there is a trade-off between development time and runtime performance.
Maintainability. Low-level languages, such as assembly language, are not very maintainable. High-level language programs are often modular in design, and the interfaces between modules are fixed. Therefore, when a problem occurs in the system, the problem can be quickly located in a certain module and solved as soon as possible. In addition, modular design also facilitates the expansion and upgrading of system functions.
Basic performance. There are many types of languages used in the development of embedded systems. The most widely used high-level languages include Ada, C/C++, Modula-2 and Java. The Ada language is strictly defined, easy to read and understand, and has rich library program support. At present, it is widely used in defense, aviation, aerospace and other related fields, and will continue to occupy an important position in these fields in the future. The C language has a wide range of library program support and is the most widely used programming language in embedded systems. It will continue to occupy an important position in the application field of embedded systems for a long time in the future. C++ is an object-oriented programming language and has also been widely used in embedded system design, such as GNU C++. Visual C++ is an integrated development environment that supports visual programming and is widely used in GUI program development. However, compared with C++, the target code of C++ is often larger and more complex. This factor should be fully considered in embedded system applications.
(3) Software development process. The development process of embedded software is different from that of general software. It mainly includes the following steps:
(4) Software development documentation. In the development and design process of embedded products, the development phase completes the realization of the system product. At this phase, a series of documents need to be completed. These documents are very important for completing product design and maintenance. These documents include technical file catalog, technical task book, technical solution report, product specifications, technical conditions, design manual, test report, summary report, etc.
Usually embedded system testing mainly includes software testing, hardware testing, and unit testing. General system hardware testing includes reliability testing and electromagnetic compatibility testing. There are already mandatory domestic and international standards for electromagnetic compatibility.
The testing methods and principles of embedded system software are basically the same as those of general software. When testing software, test instances or test sequences are generally required. There are two sources of sequences: one is designed by the user, and the other is a standard test sequence. Regardless of the type of test instance, the instance is required to have a high probability of discovering more errors, but there are some differences in the content of the test:
(1) Embedded software must run stably for a long time.
(2) Embedded software generally does not upgrade frequently.
(3) Embedded software is often used in critical applications.
(4) Embedded software must be responsible for product failure and reliability together with embedded hardware.
(5) Real-world conditions are asynchronous and unpredictable, making simulation testing very difficult.
Due to these differences, embedded system software testing mainly focuses on the following four different aspects:
(1) Because real-time and simultaneity are difficult to meet at the same time, most tests focus on real-time testing.
(2) Most real-time systems have resource constraints and therefore require more performance and availability testing.
(3) Code coverage can be tested using dedicated real-time tracking tools.
(4) The level of reliability testing is much higher than that of general software.
In addition, performance testing is also one of the most important testing activities that need to be completed when designing embedded systems, and it has a decisive impact on embedded systems.
Due to the special characteristics of embedded systems, the hardware and software platforms of the system are diverse, each of which is specially designed for different applications. Therefore, application software is rarely universal between platforms, and the update speed of embedded systems is relatively fast. In order to protect existing investments, make full use of existing software resources and speed up product development, software transplantation has become very frequent in the embedded field.
I have devoted myself to the research of technology for more than 30 years. I am proficient in various languages such as Java, Linux, JavaScript, PHP, CSS, etc. I have made many contributions in the field of open source. I have established a developer documentation site to share some problems in technology development for everyone to read.
