|
The massive amount of software in today's telematics and infotainment systems can cause significant delays at integration time, when unexpected interactions between software components can result in conditions from a slow user interface to complete system failure. Using a handsfree phone system as an example, this series of articles explores how time partitioning can prevent these problems, resulting in faster integration, better CPU utilization, and highly predictable performance.
Briefly stated, time partitioning allows the system designer to allocate a guaranteed portion of CPU time to every software subsystem, thereby preventing any subsystem from monopolizing CPU cycles needed by other subsystems. Other techniques for solving integration problems will also be discussed, such as priority reassignment and code optimization, and a comparison of their benefits to those of partitioning.
Starving one task to feed another
Anyone who has worked on a complex embedded system looks forward to final integration with a mixture of excitement and dread: Excitement because you are about to see the realization of all your hard work, dread because some of the most difficult problems crop up during this phase.
Even if the development team has carefully designed and coded every software component, complex interactions can arise among components that haven't been fully tested together. In particular, some components may inadvertently starve other components of CPU time, causing a variety of unwanted and mysterious system behaviors. Such problems typically remain hidden until the bitter end, making them difficult and time-consuming to resolve.
In most cases, the system designer will have carefully estimated the total processing budget, typically by adding up the million instructions per second (MIPS) estimates of the various building blocks. This method isn't perfect, but is often the only one available. Unfortunately, it can't account for bursts or spikes in processor usage. Thus, despite everyone's best efforts, some use cases will overtax the system, resulting in conditions from an unresponsive human machine interface to total system failure.
Traditional solutions range from code optimization to system redesign, all of which add pressure to already tight product schedules.
A different approach
Time partitioning offers a new approach to addressing such problems. Using this technique, system designers can group software components into separate partitions and allocate a guaranteed portion of CPU time to each partition. Each partition provides a stable, known runtime environment that development teams can build and verify individually. If the software processes within a partition perform well during unit testing, they will, with a high degree of confidence, exhibit the same performance at integration time.
In this series of articles, we'll examine an integration problem and review a software simulation that makes it possible to experiment with various solutions. The simulation underscores the limitations of priority-based thread scheduling and shows how time partitioning can address these limitations, allowing an existing design to avoid CPU starvation, achieve better real time performance, and offer higher availability of applications and services.
An example of the problem
A hands-free module connects to the driver's mobile phone via Bluetooth, and uses a microphone and the car's speakers to let the driver communicate with the remote party. The figure below shows the data flow. (Some systems—OnStar, for example—use an integrated phone, but otherwise operate similarly.)
Green arrows: These represent the outgoing audio path, which flows from the driver to the remote party. The driver speaks into the microphone, which is directly wired to the hands-free module and located in the rearview mirror. The module communicates with the Bluetooth phone and, after the phone has connected a call, transfers the outgoing audio to the phone. The phone then sends the audio to the person at the far end.
Yellow arrows: These represent the return audio path. The phone transmits audio from the remote party to the hands-free module, which then passes the audio to the car speakers. The module is connected to the vehicle's audio system, either directly or through a vehicle bus such as MOST.
Complications arise because the microphone also picks up output from the speakers. Left uncorrected, this situation will create a feedback loop. The hands-free module must remove the resulting echo so that the signal doesn't devolve into screeching feedback. The microphone may also pick up road noise, turn-signal clicking, wind or defroster blowing, internal acoustic echoes, and a variety of other sounds. The hands-free module has to process and remove some or all of these. It may also apply signal processing to the audio coming from the phone to improve speech intelligibility and audio quality.
Hands-free signal processing algorithms typically have strict latency requirements. For instance, if an algorithm can't process signals within 30 milliseconds, audio artifacts may become noticeable to the user. The longer the latency, the more severe the distortions become. The problem is, a typical hands-free module does more than process audio; it must also perform other tasks, such as:
monitoring the vehicle bus to log or to process messages sent by other modules within the vehicle
scanning digital radio broadcasts for traffic information
following navigation routes
Handling these other tasks during a hands-free call could temporarily stall the audio stream, which the user would hear as pops or noise.
A standard solution is to offload the audio processing to a dedicated speech processor, an approach that complicates the system design and increases the bill of materials costs. Alternatively, the system designer could use a real time operating system (RTOS), which allows a general-purpose processor to run a large number of tasks concurrently, including signal processing algorithms with strict latency requirements. Using this approach, the system designer can add features to the hands-free system while bringing down the total system cost.
|
