RT, Embedded Systems

Hamid Vakilzadian (right in picture), from the University of Bebraska-Lincoln, presented an overview of real-time and embedded systems in the 4th unnamed track. The presentation was attended by about 15 people.

The presentation started with an overview of computers and the Von Neumann Architecture as background for what goes into an embedded system. Embedded systems were then defined as hardware-software systems dedicated to pre-defined tasks. Examples given included pacemakers, ATM machines, and GPSes. They contain dedicated processors responding to external input in order to meet real-time constraints, which come in many forms (performance, reliability, and form factor for example). They are composed of lightweight hardware such as 8, 16, and 32-bit microprocessors with 10-64MB of on-chip RAM, with design times approaching months rather than years.

The presentation then progressed into a discussion of embedded system components. The platform can consist of any combination of microprocessors, programmable logic, and other specialized components. Processors have good software support such as real-time operating systems (RTOS) and are made by many manufacturers but lack hardware flexibility and aren't as fast as custom logic. Programmable logic (FPGAs, CPLDs, etc), by contrast, are fast and flexible with high degrees of parallelism but require knowledge of HDLS, have longer development times, and are harder to debug. Most of the time here was focused on these components but RTOS and real-time databases were also mentioned.

So far the presentation focused on embedded systems and so naturally the speaker moved on to a discussion of real-time systems. Real-time constraints can be classified as either hard, soft, or firm. Hard constraints are critical, meaning that violations result in catastrophic failure. Soft constraints are not critical but utility may gracefully decline over time. Firm constraints are those who utility value drops rapidly after a certain period of time. In other words, if it can't be done by the deadline it may as well not be done. A car cruise control system was given as an example of these types of constraints.

The presentation covered the embedded system design process last. Design complexity is increasing faster that designer productivity so the process is evolving. Techniques to support design complexity include delayed hardware/software partitioning, abstract and decomposition based design, iterative development, description languages, and simulation. Hardware and software have traditionally been designed separately and then integrated at the end but this approach often results in schedule delays, poor quality designs, and costly modifications. The proposed approach is to add an integrated modeling substrate where hardware and software designers collaborate throughout the design process.

The presentation finished with questions. One person asked about the speaker's opinion of what was going on inside Toyota right now. He thinks it isn't a braking problem but mentioned that debugging intermittent failures like these can be very difficult.