Certification Channel

Certification refers to the process that confirms that a system exhibits certain characteristics. The certification series focuses on the issues facing designers that need to certify that their design complies and meets some standard. It also addresses how designers can use certified subcomponents within their designs to simplify the certification of the overall system.

How could easing restrictions for in-flight electronics affect designs?

Wednesday, March 28th, 2012 by Robert Cravotta

The FAA (Federal Aviation Administration) has given permission to pilots on some airlines to use iPads in the cockpit in place of paper charts and manuals. In order to gain this permission, those airlines had to demonstrate that the tablet did not emit radio waves that could interfere with aircraft electronics. In this case, the airlines only had to certify the types of devices the pilots wanted to use rather than any of the devices that passengers would want to use. This type of requirements-easing is a first step toward possibly allowing electronics use during landings and takeoffs for passengers.

Devices, such as the Amazon Kindle, that use an E-ink display, can emit radio emissions that are less than 0.00003 volts per meter (according to tests conducted at EMT Labs) when in use – well under the 100 volts per meter of electrical interference that the FAA requires of airplanes. Even if every passenger was using a device with emissions this low, it would not exceed the minimum shielding requirements for aircraft.

A challenge though is whether allowing some devices versus others to operate throughout a flight would create situations where enough passengers might accidently leave on or operate their unapproved devices so that taken together – all of the devices might exceed the safety constraints for radio emissions.

On the other hand, being able to operate an electronic device throughout a flight would be a huge selling point for many people – and this could lead to further economic incentives for product designers to push their designs to those limits that could gain permission from the FAA.

Is the talk about easing the restrictions for using electronic gadgets during all phases of a flight wishful thinking or is the technology advancing far enough to be able to offer devices that can operate well below the safety limits for unrestricted use on aircrafts? I suspect this on-going dialogue between the FAA, airlines, and electronics manufacturers could yield some worthwhile ideas on how to ensure proper certification, operation, and failsafe functions within an aircraft environment that could make unrestricted use of electronic gadgets a real possibility in the near future. What do you think will help this idea along, and what challenges need to be resolved before it can become a reality?

How do you handle obsolescence?

Wednesday, March 9th, 2011 by Robert Cravotta

Producers and users are both involved when a product, component, or technology is slated for obsolescence, but both parties do not always agree that the obsolescence is appropriate. Take for example Microsoft’s efforts to kill Internet Explorer 6 (IE6). The company recently launched a website called ie6countdown.com with the intent to track and encourage people to migrate away from the ten year old web browser. As of February 2011, 12% of worldwide users are still using IE6 as their browser – this represents a sizable group of people that present a support challenge for Microsoft and web content developers. According to Roger Capriotti at Microsoft, their goal is to get the worldwide share down to below 1% because they believe that 1% will allow more sites and IT pros worldwide to make IE6 a low-priority browser.

One thing I was not able to discover on the tracking website is the type of machine these IE6 users are running the browser on. I suspect that the underlying hardware may play a larger role in the continued use of the browser that will be three generations behind the latest browser (IE9) as of March 14th.

For embedded developers, the obsolescence of components can wreak havoc. While the end user may not even be aware of the embedded systems in their end devices, changing the implementation of an embedded system is no trivial task. That is why on many aerospace programs I worked on we specified that the microprocessor that we selected must be available to support a twenty or thirty year support window. Now that did not mean the processor supplier had to keep manufacturing those processors for all of those years, but it did mean that there was a plan to pre-produce and store those processors against some usage plan for that period of time.

Part of the reason for continuing to use the older processors was that it was too risky and expensive to upgrade the system to the latest generation processors. Even though a processor may be fully backwards compatible, the interfaces and timing differences of system events could shift just enough to cause intermittent failures in the end system. To upgrade a processor would entail a complete recertification, and for some systems, that is an unjustifiable expense to only maintain the functionality of a system.

Maintaining older generations of components beyond their production life cycle can also apply to software modules. Changing the operating system in an embedded system may also require a recertification, so it is safer and more cost effective to freeze the operating system at a specific configuration and version.

How do you handle obsolescence – both as a producer and as a user? As a producer, this question is most interesting when your user base wishes to continue using your product beyond your planned production cycle. As a user, this question is interesting as a way to explore different strategies to maintain a frozen design or migrate the design without incurring product killing costs.