Embedded systems range from portable devices such as digital watches and MP3 players, to large stationary installations like traffic lights, factory controllers, and largely complex systems like hybrid vehicles, MRI, and avionics. Complexity varies from low, with a single microcontroller chip, to very high with multiple units, peripherals and networks mounted inside a large chassis or enclosure. Future trends in embedded systems will include revolutionary technologies such as embedded security, real-time data visualization, network connectivity, and the IoT, and deep learning capabilities.
Embedded System is an electronic system or device which employs both hardware and software. A processor or controller takes input from the physical world peripherals like sensors, actuators etc., processes the same through appropriate software and provides the desired output. The various components have to communicate with each other to provide the anticipated output.
Many embedded system based solutions being oﬀered these days require interconnecting many individual embedded systems. An automobile system as such has in it many embedded systems which individually deals with controlling breaks, doors, mirrors, rare and front object indicators, engine temperature, wheel speed, tyre pressure, DVD control etc. Establishing communication among various microcontroller based systems is essential to implement a distributed embedded application.
Communication Protocols are a set of rules that allow two or more communication systems to communicate data via any physical medium. The rules, regulations, synchronization between communication systems, syntax to be followed and semantics are all defined by the term protocol. Protocols can be implemented by both hardware and software or combination of both.
Networking of embedded systems can be achieved in many ways using protocols such SPI, FireWire, USB, CAN, I2C, PCI, and ESA etc. The communication protocols associated with physical layer describe the signals incorporated, signal strength, hand shaking mechanism, bus arbitration, device addressing, wired or wireless, data lines etc.
Communication protocols are broadly classified into two types, Inter System Protocol and Intra System Protocol. Inter system protocols establish communication between two communicating devices i.e. between PC and microprocessor kit, developmental boards, etc. In this case, the communication is achieved through inter bus system.
Inter system protocol can be categorized into, USB Communication protocols UART Communication protocols and USART Communication protocols. Asynchronous serial is used UART chip for the communication. There is no specific limit defined for asynchronous communication but most of the serial devices support up to the maximum baud rate of 230400.
The Intra system protocol establishes communication between components within the circuit board. In embedded systems, intra system protocol increases the number of components connected to the controller. Intra system protocol can be categorized into, I2C Protocol, SPI Protocol and CAN protocol.
I2C and SPI are both bus protocol to allow the user for short-distance, serial data transfer. I2C is two wire communication which made by the Philips (Nowadays NXP) and SPI is made by the Motorola.
I2C is a serial communication protocol. It provides the good support to the slow devices, for example, EEPROM, ADC, and RTC etc. I2C are not only used with the single board but also used with the other external components which have connected with boards through the cables.
I2C is basically a two-wire communication protocol. It uses only two wire for the communication, instead of the 8 or more pins used in traditional parallel buses. These two signals are called SCL (Serial Clock) which synchronize the data transfer between two chips, and SDA (Serial Data). This reduction of communication pins reduces the package size and power consumption.
In I2C, both buses are bidirectional, which means master able to send and receive the data from the slave. I2C is a half-duplex protocol. I2C is a synchronous serial protocol; each data bit transferred on the SDA line is synchronized by a High to Low pulse of clock on SCL line. I2C can be multi-master and multi-slave.
I2C is ideal to attach low-speed peripherals to a motherboard or embedded system over a short distance is required. I2C provides a connection oriented communication with acknowledge. Additionally, an I2C bus is used in the various control architecture, for example, SMBus (System Management Bus), PMBus (Power Management Bus), IPMI (Intelligent Platform Management Interface) etc.
In 1980, electronics manufacturer Motorola wanted to design a communication protocol for its microcontroller-operated embedded systems that would allow full-duplex synchronous serial communication between master and slave devices on the bus. The resulting innovation in embedded systems programming, which later became known as Serial Peripheral Interface (SPI) protocol, has become a leading de facto standard for short-distance communication in embedded systems.
Sometimes called a four-wire serial bus, a basic SPI bus consists of an SPI master device and an SPI slave device connected by four wires. Two of the wires act as a signal line that can be used to transmit data, either from the master to the slave or in the opposite direction. Another line is used for clock and the fourth line is used to designate the target slave device for communication.
In an SPI system, the master devices set the clock frequency and configure the clock polarity and phase. Data is only sampled at specific frequencies, so it is crucial that the master device and slave device are properly in time with each other.
The design of the SPI protocol supports fast data transmission speeds, full duplex ommunication, and versatile applications in a variety of embedded systems. The simple, intuitive, and efficient design of the SPI protocol makes it an ideal choice for embedded systems development.
Comparison of I2C with SPI
For engineers working with embedded systems, there are a few different options as far as choosing a communication protocol. The most popular options, however, are the SPI and I2C protocols that were created by Motorola and Philips semiconductor divisions respectively.
I2C supports the multi-master communication. SPI does not support multi -master communication. It is cheaper to implement than the SPI communication protocol, and less susceptible to noise than SPI. I2C ensures that data sent is received by the slave device; SPI does not verify that data is received correctly or not. I2C is better for long distance, SPI is better for the short distance.
For many applications, SPI seems to offer the best features and the versatility that engineers need to perfect their application. Here are some of the key benefits of using the SPI protocol:
SPI has earned a prominent role in embedded systems thanks to its high-speed capabilities, relatively low power consumption, and space-efficient design. There are many types of embedded systems that make use of the full-duplex communication capabilities offered by SPI devices, especially devices for digital signal processing or telecommunications.
SPI is a diverse communication protocol that is suitable for many types of embedded systems. SPI protocol has been used to design systems with many different types of peripherals, including temperature sensors, touch screen monitors, audio codecs, communication and networking devices, real-time clocks, and more.
When designing an embedded system, it is important to consider how the speed of the system will impact user experience. Slow data transfer can make the device seem sluggish and unresponsive for the end user, so it’s important to choose a communication protocol that offers rapid data transfer.
SPI’s major alternative, the I2C protocol, was originally designed for data transfer speeds of just 100 kHz – although improvements to data transmission modes have seen speed increases for I2C systems over the years. Meanwhile, systems that make use of the SPI protocol can achieve data transfer speeds in excess of 10+ MHz, making them must faster than systems that use I2C.
Part of the reason for the huge speed difference between I2C and SPI comes down to the complexity of the bus protocol that underlies I2C. I2C systems may support several masters on the bus, use intentional communication delays to arbitrate bus access and operate with a set maximum bus rate of between 10 kHz in low-speed mode and up to 5 MHz in high-speed mode. In contrast, the simple architecture of SPI minimizes bus overhead and there is no maximum bus rate, meaning no cap on communication speeds.
SPI Supports Full Duplex Communication
In addition to facilitating faster communication, SPI devices also run in full duplex by default, whereas I2C devices are by default in half-duplex. Here’s how the difference works:
An I2C bus system has a single bi-directional line for data transmission between a master and slave. This means that while the master device is transmitting data to the slave, the slave must be receiving the data. Data can only travel in one direction at a time because there is just a single line for transmission. On the other hand, SPI systems have a MISO line and a MOSI line so the master and slave device can communicate bidirectionally at the same time.
Controller Area Network (CAN)
A controller area network (CAN) is a message-based protocol that allows internal systems to communicate with one another without a central computer. CAN technology is used in applications as wide-ranging as agriculture, robotics, industrial automation and medical systems, but it is most known for its use in the automotive industry.
In today’s connected vehicles, the CAN bus facilitates communication between UGVs microcontrollers (MCUs) along a larger vehicle bus, without the use of a central computer. For example, the cruise control system can quickly communicate with the anti-lock braking system to disengage when a quick stop is needed.
The more complex vehicles become, with ever-more interconnected MCUs needing to transfer information, the more important the reliability of the vehicle bus becomes. And with each model year bringing new cameras, sensors and display screens, the efficiencies that CAN provides in the physical layer of a vehicle become more attractive. In the past, cars were limited in their features due to the finite amount of space for the physical cables and complex wiring that was required for each system to communicate. CAN allows for a leaner networked system that not only underlies the connected vehicles of today, but also the drive-by-wire functionality necessary for the autonomous vehicles of tomorrow.
What Sensors Are Attached to the CAN Bus?
The technologies that enable autonomous driving can vary slightly, but they all require advanced vision and sensing equipment to “see” the road ahead, as well as high-powered software to make decisions based on that visual information. Most autonomous military vehicles would support some combination of the following sensors, among others:
- Light Detection and Range (LiDAR) technology, for creating a 3D map of the road ahead;
- Color cameras, for determining the changing position of the road and other obstacles in front of the vehicle;
- Infrared cameras, adding another layer of complexity to obstacle-sensing;
- GPS, for navigation and creating a larger contextual map that the vehicle can reference.
Drones and Autonomous Vehicles
With autonomous vehicles, and especially autonomous tactical vehicles, the in-vehicle networks supporting the advanced vision and sensing technologies require a higher bandwidth connection like those provided by Ethernet or FlexRay. But these connections can combine with CAN or CAN FD (CAN with flexible data rate) to create a robust network that is flexible when performing tasks that require high-data throughput, and that is quick and reliable when performing more simplified communication tasks.
The use of the CAN bus isn’t just limited to UGVs. Unmanned aircraft systems (UASs) have also adopted CAN technology for its low-latency, reliable communication capabilities. In fact, there’s even a UAVCAN protocol designed for aerospace and robotic applications. The CAN bus allows for communication between embedded systems within a UAV, as well as the transfer of information between a UAV and the remote operator.
For instance, the CAN bus can allow the flight controller to manage the throttle on the electronic speed controller (ESC), but it also allows the ESC to return hard real-time data to the flight controller, including temperature, amperage, voltage, warning signals, etc. via live telemetry. The real-time data, transferred within microseconds, allows remote pilots to react immediately, making for much safer and more reliable UAV flight operations.
CAN bus has been the communication standard for embedded systems in vehicles for decades, and even huge leaps in vehicle technology like electric and autonomous vehicles have continued to utilize the CAN bus due to its flexibility and reliability. These same features make CAN an ideal component for autonomous military and defense vehicles, including UGVs and unmanned aerial vehicles (UAVs), or drones.
In addition to its functionality, CAN’s inherent ruggedness is a clear draw, performing just as consistently in extreme heat and cold as it does in arid and dusty climates and extremely wet conditions.
Commercial autonomous vehicles must have highly attuned sensors when navigating city streets – able to sense changing road conditions, other vehicles and pedestrians. Tactical military vehicles, on the other hand, must be prepared for off-road conditions in every kind of hostile environment. The obstacles are greater and the consequences are higher stakes. That means that a higher priority must be placed on sensors and algorithms that can calculate and make split-second decisions; and the need for near-instantaneous, error-free communication is critical. CAN enables all of these complex systems to communicate with the clarity and speed that are necessary when lives are on the line.
Many military vehicles make use of the CAN bus to log and transfer periodic operational data that are reviewed by maintenance personnel (or, more likely, computer algorithms) for predictive maintenance – in other words, analyzing operational data to look for potential vehicle maintenance issues so that they can be addressed before they become critical.
To account for the many issues specific to military vehicles, a working group of the International High Speed Data Bus-Users Group (IHSDB-UG) developed the MilCAN higher layer protocol in 1999, with the goal of creating a standard interface for utilizing CAN bus in military vehicle development. There are two versions of MilCAN: Mil-CAN A and MilCAN B.
Widely used in armored vehicles, MilCAN A uses 29-bit identifiers and uses a similar frame format to SAE-J1939. Mission-critical in mind, Mil-CAN A prioritizes message transmission, and defines 1-Mbit, 500-Kbps, and 250-Kbit communication rates.
MilCAN B is actually an extension of the CANopen application layer, using 11-bit identifiers and only periodically allowing data to be transmitted via the bus. MilCAN B supports data rates from 10 kbps to 1 Mbps.
Both protocols were developed to specialize the use of CAN around deterministic data transfer, so the specifications can also be used for non-military applications.
Even though Ethernet has existed for over 20 years, it could not be previously used in
automobiles due to the limitations such as : Ethernet did not meet the OEM EMI/RFI requirements for the automotive market. 100Mbps (and above) Ethernet have too much RF “noise,” and Ethernet is also susceptible to “alien” noise from other devices in a car. Ethernet could not guarantee latency down to the low microsecond range. This was required to replace communication to any sensor/control that needed fast reaction time. Ethernet did not have a way of synchronizing time between devices and having multiple devices sample data at the same time.
Today, Ethernet is only used in cars for diagnostics and firmware updates. 100Base-Tx is
the typical standard used. This standard does not meet automotive EMI requirements, but
as this interface is only used for diagnostics while the car is in a service location (not in
motion), an exception was made to allow its use. Cars that use Ethernet for diagnostics
typically have an RJ45 connector that is used to connect to an external computer that runs
the diagnostics software. Firmware upgrades on some cars are also done through this
interface due to its much higher speed.
There are multiple proprietary standards for communication in a car, including analog
signals on wires, CAN, FlexRay, MOST, and LVDS. Each vehicle component typically has its
own dedicated wiring and communication requirements. Due to this complex cabling, the wiring harness is the 3rd highest cost component in a car (behind the engine and chassis). Harnesses are built one at a time, and comprise 50% of the cost of labor for the entire car. The wiring harness is also the 3rd heaviest component (behind the chassis and engine). Any technology that reduces this weight directly contributes to fuel economy. A joint study by Broadcom and Bosch estimated that using “unshielded twisted pair (UTP) cable to deliver data at a rate of 100Mbps, along with smaller and more compact connectors can reduce connectivity cost up to 80 percent and cabling weight up to 30 percent.”
Automotive Ethernet is a physical network that is used to connect components within a car using a wired network. It is designed to meet the needs of the automotive market, including meeting electrical requirements (EMI/RFI emissions and susceptibility), bandwidth requirements, latency requirements, synchronization, and network management requirements.
The old model of automotive wiring harnesses will change from heterogeneous networks of
proprietary protocols (such as CAN and MOST) to hierarchical homogenous automotive Ethernet networks. In the new model, switched 1GE automotive Ethernet will interconnect all the domains in the car (meaning that Ethernet will be a shared medium with signals controlling throttle sharing the same twisted pair as a request to change the radio station and the video for the kids in the back seat). The new anatomy not only helps reduce cost and weight, but also makes it much easier for the different systems in the car (and outside of the car) to cooperate.
To fully meet the automotive requirements, multiple new specifications and revisions to
specification are being done in the IEEE 802.3 and 802.1 groups.