GridSTAR Opening

I just returned from the grand opening of the GridSTAR center at the Philadelphia Navy Yard. This center was created by Penn State and the Department of Energy as a combined education and research center for smart energy grids.  Their first demonstration is this model home.  It both demonstrates a number of smart grid technologies as well as providing a training center for people to develop the skills required to work on these new systems.  The smart home includes three buildings.  The house itself demonstrates systems ranging from solar panels to radiant heat.  The learning center in back has a number of electrical systems installed inside that can be used for training.  The third building contains an energy storage system that is hooked into the Navy Yard grid.

They also showed cool systems  like this solar-powered electric car charger...

and this electric motorcycle.

Over the longer term, GridSTAR will use the entire Navy Yard as a testbed for smart energy technologies.  Given the wide range of businesses there, ranging from a major shipbuilder to the headquarters of Urban Outfitters, the Navy Yard should be a great place to develop new smart enertg grid solutions.

Farewell, Cyber-Physical Sewing Machine!

I am retiring one of my cyber-physical machines---my sewing machine, to be precise.  You can see the source of the problem in the photo, namely the ribbon cable to the front panel.  The front panel is attached to the body with a very small tongue and a little adhesive.  When it comes loose, it pulls the cable out of its connector.  This little four-bit microcontroller costs $120 to replace; I know because it has happened before.

I have replaced it with an old-fashioned mechanical sewing machine, one built by Toyota, no less.  It has metal gears and no computer.  Toyota, of course, has had its own problems with cyber-physical systems, but I am confident that they know how to make a reliable gearbox.

While we are on the subject of sewing machines, let's take a minute to consider the genius of the sewing machine and its inventor, Elias Howe. The mechanism of the sewing machine performs a fiendishly complicated motion to perform what seems to be impossible---it wraps one thread around another.  Since Mr. Howe worked before the midpoint of the 19th century, he had no computers to control his machine.  He relied on simple rotating machines and cleverness.  150 years later, we still use his work.  As we design complex cyber-physical machines, let's remember that our goal should be to create designs that last.

Car Electronics: E/E

I've found a term I hadn't heard before: E/E.  It refers to the electrical/electronic architecture of a car.  Automotive has never had a term like avionics for airplanes, so this term is really past due and welcome.

One of the elements of E/E that has been around for awhile now is AUTOSAR, or Automotive Open Systems Architecture.  It is a standard that concentrates on engine control units. The OSEK OS, an ISO standard (ISO 17356-3) is the foundation for the specification of the operating system; it specifies the interfaces to the task-oriented functions of the OS.  AUTOSAR also specifies an AUTOSAR Runtime Environment that provides middleware functions for the applications.  A Microcontroller Abstraction Layer (MCAL) abstracts the microcontroller's hardware to provide a standard interface for functions such as I/O and flash.  AUTOSAR also includes a methodology for configuring an AUTOSAR-compliant system from its components.

Hardware Assurance

The term hardware assurance has been circulating for the past couple of years.  This term refers to assurance that the hardware you have is the hardware you think you paid for.  Counterfeit electronic hardware has become a big problem for the military---they pay big money for equipment that turns out to be fraudulent and non-functional.  Companies are increasingly concerned about the effects of counterfeit hardware on their bottom line---not only do they lose the sale to the counterfeit, but they often have to pick up the warranty costs for those counterfeits, too.

At the most basic level, hardware assurance ensures that components have not been substituted.  One way to provide such assurance is through supply chain management: auditing, custody chain tracking, etc. SAE has developed a standard, AS5553A, for the documentation and procedures to be followed to ensure a reliable supply of components from suppliers.  That standard, of course, needs to be followed not just by your supplier but by their suppliers as well.

Programmable memories are, of course, an easy way to attack programmable devices.  Andrew Appel of Princeton University has demonstrated the ease with which ROMs on New Jersey's voting machines can be substituted, allowing the voting machine to be reprogrammed.

A more subtle version of this problem rears its head in the semiconductor world.   If you give a set of masks to a semiconductor manufacturer, how do you know that they manufactured the circuit you gave them?  Not only may they have manufactured junk, but they may have introduced Trojan horses into your hardware that they can exploit at later dates.  Various techniques have been developed to deal with this problem.  Netlists can be used as watermarks to verify that the design has not been changed.

Yet another subtlety comes into play for embedded devices---how do you know that a device in the field hasn't been swapped?  Even if a device leaves your plant with the correct hardware, it may have been compromised after installation. Physically unclonable functions (PUFs) can be used to generate a unique signature for each device that can be checked in the field.

Thermal-Aware Computing

Temperature has reared its head as an important issue.  And it's not just a challenge for server farms.  All types of embedded devices must be designed to meet thermal-related design specifications.

Thermal behavior affects system operation in several ways.  Heat generation causes problems for the environment in which the device operates.  In machine rooms, we want to pack as many CPU and disk drives into the room as possible; perhaps even more important, we don't want to spend any more money than we have to cooling the room.  Thus, the simple quantity of energy transferred into the room from the processor is a big issue in machine rooms.  Machine room designers also have to worry about how air circulates.   Poor air circulation leads to hot spots that cause devices to fail.

Excess temperatures also lead to catastrophic component failure.  And I don't use the word catastrophic lightly.  Search for "overheating pentium" on youtube to find a variety of videos that show CPUs running so hot that they start to smoke.  These failures are so catastrophic because they are the result of positive feedback: high temperatures increase leakage currents; high leakage currents increase temperature.

In consumer electronics, the traditional goal for temperature management has been to avoid fans. A fan, even a well-designed one, creates some amount of background noise that is particularly undesirable in multimedia applications.  Of course, a fan on a cell phone is just plain ridiculous.  Today's cell phones can get pretty darn warm to the touch if you run a data-intensive application for a few minutes.

But temperature has a more subtle effect on system lifetime.  A CPU doesn't have to catch fire to be damaged.  Chips can fail in all sorts of ways: dopants rediffuse, oxides break down, wires break down.  Most of these failure mechanisms are temperature-dependent and can be an exponential function of temperature.  The hotter you run, the shorter your lifetime. Running just under the maximum temperature for your device doesn't avoid trouble.

Embedded Systems Week: Mixed-Criticality and Model-Based Design

Today at Embedded Systems Week, I attended the special session on mixed-criticality systems.  This is a relatively new formulation of real-time systems in which tasks are grouped into levels of criticality.  Tasks in the higher levels of criticality are given priority over lower-criticality tasks when resource constraints arise. As we put more and more functions into systems, we need to understand how to manage criticality.  Imagine, for instance, the electronic systems in your car.  The engine controller and radio both run on the same computing platform, but we want to be sure that the engine controller is viewed by the system as more critical than the radio.  The panelists did a good job of explaining the importance of the problem, what progress we have made on mixed-criticality in a few short years, and what we still need to do.

I also attended the special session on model-based design.  The panel considered efforts to take the next-step from models as documents and tools to models as the only artifacts used for complex system design.  The panelists walked us through an example model-based design, including verifying a simple specification.  They also talked about the complexities of using models for real-world system.  Given the huge number of different modeling languages in use, each with its own advantages, it is unlikely that we will ever have a single, unified modeling language for all systems.  The panelists instead advocated using a collection of application-specific languages tied together with tools that cross-check properties of the individual models.

Embedded Systems Week: Systems Engineering and Run-Time Adaptation

Monday's keynote at Embedded Systems Week came from Clas Jacobson, Chief Scientist at United Technologies Systems and Controls Engineering.  UTC designs a lot of complex cyber-physical systems, including elevators, car subsystems, and jet engines.  Dr. Jacobson identified three As as important in CPS design: architecture, abstractions, and automation.  He stressed the importance of good modeling as the foundation of robust system design.

I also attended a session on run-time adaptation with presentations by Joerg Henkel, Vijay Narayanan, Sri Parameswaran, and Juergen Teich.  Determining all aspects of system operation at design time simply doesn't work for today's complex systems.  The computation required depends on the input data---image/video compression is a classic example of a complex relationship between image/video data and compression time.  The complexities of thermal management are also best handled in many cases with run-time systems.  The talks gave a multi-level view of the problem.  Joerg's talk concentrated on thermal, including  a cool infrared video of chip temperature over time.  Vijay's talk looked at the opportunities presented by tunneling transistors, which provide good off characteristics but are slower than traditional MOSFETs.  Sri's talk looked at video compression and how to manage the complex pipeline required to perform all the steps required for compression.  Juergen's talk described a new model of computaiton for run-time management known as invasive computing.