Saturday, September 22, 2012

Why a Phone Needs a Real Time OS

If you pay any attention to smartphone advertising you will recognize a number of trends. One of them, in common with larger platforms, is the ever increasing processor power and speed. There are many benefits to having faster, more powerful CPUs to run ever more complex and engaging applications and games on, but this advance does not come without costs, especially in size constrained hardware such as mobile phones. Quite often faster data processing is pursued when real time performance is needed. There is often confusion between the two.

What is Real Time Computing?

Real time computing is the study of systems that are subject to real world time constraints. One example is an automotive anti-lock breaking system. The system must integrate data such as break peddle pressure to gauge the level of breaking desired by the driver, break pad pressure and wheel rotation rate to compute the amount of traction available for breaking and compute the optimal pad pressure to apply to each wheel all before any of the wheels lock up. In human terms this requires 'split second' response times and calls for fast computation. 

An equally valid example is a debit card or credit card point of sale terminal. When a customer elects to pay with one of these electronic options data must be exchanged between the terminal, the customer's bank and the merchant's bank. This exchange does not have to happen in a split second, but if it takes more than a few dozen seconds the usability and satisfaction with the electronic payment option begins to degrade. 

Real time computing systems deal with both these cases by providing a guaranteed response within the time constraint period. The anti lock breaking system is an example of a hard real time system; not responding within the constraint period results in wheel lock. A total system failure. The point of sale terminal is an example of a soft real time system; the value of the response, or the satisfaction of the customer, degrades if the system fails to respond within the constraint period.

Clearly some real time problems require very powerful and very fast processors, perhaps many of them working together. Speed and power do not, however, equate to real time. This is especially true of multi-user or multi-process system, which includes almost all recent computers from large mainframes, through desktops, tablets, and smartphones. The problem arises when two or more processes want to change one piece of data on the system. They could all want to write to one file, send a data packet out on the one network interface or set a particular pixel on the display to a different colour. If one process starts to write to a file and then is paused to give another process a change to run (doing this very rapidly is how the computer can look like it is doing many things at once), and the second process also starts to write to the file, the file will be corrupted so that neither process will recognize the contents as correct. To prevent this from happening operating systems provide mechanisms that ensure once certain operations start they aren't interrupted until they are completed, or at least progress to a stable state. While one process is using a resource protected by this mechanism no other process could use that resource. If one process holds onto a resource through a response deadly the real time response fails.

It doesn't have to be multiple processes writing to one resource. In may cases we also want to prevent one process reading what another process has written unless we can be sure the data is consistent. Let's use a sophisticated traction control system as an example. In our system we are going to integrate engine torque, steering angle, all four wheel rotation rates and all four wheel brake pressures and have the system decide if more or less break pressure should be applied to each of the wheels to maintain traction in all conditions. We have a modern dual core processor to do the work on so we divide the task into two processes: one reads all the data from the sensors, converts the data into numbers that can be used by our traction control algorithm and writes the numbers into shared memory; the other reads the numbers, computes the new break force parameters and sends commands to the break actuators. It is critical that the second process only reads the data from shared memory between the time all the data has been written and the first process starts writing the next data set. We don't want our algorithm to use a mix of data from now with data from some time in the past. If we want our system to adjust break force 200 times per second, then each process must complete one processing cycle every 5 milliseconds. This cycle must allow time for the other process to write to, or read from the shared memory. If these deadlines are not met break pressure may be applied too late, or left on too long resulting in a car that is more difficult to drive rather than easier. The break may be applied and not release, or worst case not engage even when the driver presses the break peddle.

Real Time in the Palm of Your Hand

So, is your smartphone ever going to control systems in your car? Maybe not. So why do you want a smartphone with a real time operating system? Well, just today as I'm writing this a person has posted to Slashdot.Org asking about smartphone controllable hearing aids. Consider walking down the street and into a Starbucks while chatting with a friend. Our hearing impaired musician would want to adjust his aids to the changing background noise from outside to inside, ordering a latte, then continuing the chat at a table. A user may prefer to do this manually but it is certainly a task that could be done automatically based on location and ambient sound picked up by smartphone microphone. If the application was several seconds late in making the adjustments only a few times per day the annoyance and reduction in usability may cause the user to stop using the application. On a modern smartphone with Google Latitude, Twitter, Facebook, Email, the phone and other apps all competing for processor time if there is no way to prioritize and ensure that the important processes get the resources they need in time this kind of application will ultimately fail. There are many other potential use cases: insulin pumps, prosthetic limb adjustment, navigation for the blind, and so on. 

On the other hand there is the more mundane general case of just having the phone respond to user input smoothly with no perceptible delay. If poorly written applications can have too many processes waiting for scarce resources then the responsiveness of all process will suffer. A well written real time operating system can be used to ensure that the user input is processed and delivered to the application that needs it along with the run time so the user experience remains positive even on a heavily loaded phone.  

No comments:

Post a Comment