Reliability and Failure Prediction: A New Take

HALT methodology has been a popular way to test harsh environment reliability. A new approach involves PCB design simulation for vibration and acceleration for deeper yet faster analyses.

By Craig Armenti & Dave Wiens—Mentor Board Systems Division

Many electronic products today are required to operate under significant environmental stress for countless hours. The need to design a reliable product is not a new concept, however, the days of depending on a product’s “made in” label as an indicator of reliability are long gone. PCB designers now realize the importance of capturing the physical constraints and fatigue issues for a design prior to manufacturing to reduce board failure and improve product quality.

Simulation results should be available in a two-phase post-processor for each simulation, providing broad input on the PCB’s behavior under the defined conditions.

Simulation results should be available in a two-phase post-processor for each simulation, providing broad input on the PCB’s behavior under the defined conditions.

Although every product is expected to fail at some point. That’s inevitable. But premature failures can be mitigated through proper design when proper attention is paid to potential issues due to vibration and acceleration. ….

Read this article in the August 325 issue of Circuit Cellar

Not a Subscriber yet? Become one today:


Or purchase the August 2017 issue at the  CC-Webshop


Power Analysis of a Software DES Encryption Routine

This article continues the foray into breaking software security routines, now targeting a software implementation of DES. This builds on a previous example of breaking a hardware AES example.

By Colin O’Flynn

In the previous column, I broke a simple XOR password check using side-channel power analysis. How can we apply this to more complex algorithms though? In my Circuit   Cellar   313   (August   2016) story, I demonstrated how to break the AES encryption standard running on a FPGA.

The EFF’s “Deep Crack” board could brute force a DES key in a matter of days. (Photo courtesy of Electronic Frontier Foundation)

The EFF’s “Deep Crack” board could brute force a DES key in a matter of days. (Photo courtesy of Electronic Frontier Foundation)

While I originally considered breaking a software implementation of AES in this column, there was just too much overlap between those columns. So instead I decided to pick on something new. This time, I’ll cover how we can break a software implementation of DES. The actual process ends up being very similar. But by using a different algorithm, it might help give you a bit of perspective on how the underlying  attack  works.  ….

Read this article in the August 325 issue of Circuit Cellar

Not a Subscriber yet? Become one today:


Or purchase the August 2017 issue at the  CC-Webshop


The Future of IoT Security: One Size Doesn’t Fit All

Security is one of the hot topics today in the Internet of Things (IoT). There have been well-publicized security breaches of consumer devices that include hijacked video from wireless baby monitors being posted on the Internet and home automation systems that reveal whether a home is occupied or not. A number of systems have been breached just to demonstrate their vulnerabilities. Less well publicized are security breaches of industrial equipment with much more severe consequences. These are rarely made public for obvious reasons.

At first glance, it would seem that the existing security mechanism for the Internet and corporate networks would be an easy solution for IoT security. There are several problems with this. First, IoT applications only require security that is “good enough” for the specific application. Just like you don’t need razor wire and guard towers to keep your dog in the yard and don’t want to rely on a four foot yard fence to keep the prisoners in a maximum security prison, the level of security for an IoT product needs to be based on the needs of the application (often basic privacy rather than real security).

Consider data encryption for network transfers as an example of why existing security mechanisms generally do not work well for the IoT. Encryption standards typically target applications that require extremely high levels of security such as financial transactions and military or national security communications. These encryption standards are severe overkill for most IoT applications and present significant problems for small, battery-powered IoT devices. An encryption algorithm may require upwards of 4 KB of code space, which is as much or more than many otherwise suitable microcontrollers might have. Many encryption standards rely on multiple rounds of encryption. The time it takes to perform the encryption could be several times longer on a small micro than the time it takes the micro to perform its main tasks. Most common encryption standards rely on 16- to 32-byte keys to help ensure data security. For many IoT devices, these key lengths could increase the length of their network messages by a factor of 4× to 8× or more. The execution time and added network traffic can quickly chew-up precious battery capacity, increasing the size and cost of a product. The extremely high level of security provided by these encryption algorithms is what drives the large code size, long execution times, and high message overhead that makes them inappropriate for most IoT applications. Hardware encryption addresses the code size and execution time issues but still suffers from high message overhead.


The other major problem with using existing security mechanisms is IoT developers typically don’t have network security experience. There is a certain mindset and expertise required to develop IoT products and a completely different mindset and expertise required to be a security expert. The time required to develop these security mechanisms in-house could take several times longer than the basic product development. Several companies have recognized this problem and have recently introduced security framework products to be incorporated into IoT devices. True end-to-end security requires much more than just passwords and data encryption, and these framework products address other needs like key management and protection against common network attacks. These security frameworks may well be the future of IoT security, but to be widely adopted, they have to be right-sized for IoT devices.

When selecting the wireless technology to use in an IoT product, things like distance, bandwidth, cost, and physical size have to be considered. Words and phrases like “streamlined” and “light weight” need to be kept in mind when assessing security solutions for IoT products. A feature-rich security framework product might be appealing, but many IoT devices provide simple functions and don’t need a plethora of features. They also can’t afford the memory space and execution time overhead (and power consumption) imposed by these unneeded features. Whether future IoT products are based on a security framework or in-house developed security, there will not be a one-size-fits-all solution. Security for successful IoT products will be right-sized for the hardware resources available and the needs of the application.

Mike Lease is a hardware/firmware engineer with more than 30 years of product development experience, mostly in embedded products. He developed a number of battery-powered, wirelessly connected devices before “IoT” became a common buzzword, and several more since then. Mike enjoys taking on tough challenges and has recently developed a fascination with generating random numbers. In 2013 he founded CMicrotek ( to develop a family of ultra-low current measurement products primarily for developers of battery-powered products. Mike recently launched LSE Technologies, a provider of lightweight stream encryption software for M2M and IoT applications.

Light-Weight Data Encryption for IoT and M2M Applications

LSE Technologies recently announced it is enabling secure end-to-end network data transfers for M2M applications and IoT devices with its Lightweight Stream Encryption Technology (LSET) C source code packages. LSE tech

Three versions of the LSET Professional product line are available for different levels of security and processing resources:

  • LSET Pro is targeted at 8-bit and low-end 16/32-bit microcontrollers and offers basic encryption algorithm for short control/status messages.
  • LSET ProX is targeted at mid-range 16/32-bit microcontrollers with an enhanced encryption/decryption engine and key security features. It is suitable for short control/status messaging as well as video and firmware updates.
  • LSET ProXT is targeted at higher end 32-bit microcontrollers and provides a more advanced encryption/decryption engine and additional key security features. It is suitable for longer messages such as in gateway applications as well as for video and firmware updates.

On a common 32-bit microcontroller, a typical implementation of the LSET ProX package would require about 600 bytes of code space plus 64 bytes of RAM and with a 20-MHz CPU clock encryption/decryption could be performed in about 2.5 µs per byte.

The LSET source code packages were designed to be easily incorporated into existing code bases. In many cases data encryption can be added to a product in just a few hours. The LSET Professional C source code packages start at $500 for the LSET Pro package.

Source: LSE Technologies

CC266: Microcontroller-Based Data Management

Regardless of your area of embedded design or programming expertise, you have one thing in common with every electronics designer, programmer, and engineering student across the globe: almost everything you do relates to data. Each workday, you busy yourself with acquiring data, transmitting it, repackaging it, compressing it, securing it, sharing it, storing it, analyzing it, converting it, deleting it, decoding it, quantifying it, graphing it, and more. I could go on, but I won’t. The idea is clear: manipulating and controlling data in its many forms is essential to everything you do.

The ubiquitous importance of data is what makes Circuit Cellar’s Data Acquisition issue one of the most popular each year. And since you’re always seeking innovative ways to obtain, secure, and transmit data, we consider it our duty to deliver you a wide variety of content on these topics. The September 2012 issue (Circuit Cellar 266) features both data acquisition system designs and tips relating to control and data management.

On page 18, Brian Beard explains how he planned and built a microcontroller-based environmental data logger. The system can sense and record relative light intensity, barometric pressure, relative humidity, and more.

a: This is the environmental data logger’s (EDL) circuit board. b: This is the back of the EDL.

Data acquisition has been an important theme for engineering instructor Miguel Sánchez, who since 2005 has published six articles in Circuit Cellar about projects such as a digital video recorder (Circuit Cellar 174), “teleporting” serial communications via the ’Net (Circuit Cellar 193), and a creative DIY image-processing system (Circuit Cellar 263). An informative interview with Miguel begins on page 28.

Turn to page 38 for an informative article about how to build a compact acceleration data acquisition system. Mark Csele covers everything you need to know from basic physics to system design to acceleration testing.

This is the complete portable accelerometer design. with the serial download adapter. The adapter is installed only when downloading data to a PC and mates with an eight pin connector on the PCB. The rear of the unit features three powerful
rare-earth magnets that enable it to be attached to a vehicle.

In “Hardware-Accelerated Encryption,” Patrick Schaumont describes a hardware accelerator for data encryption (p. 48). He details the advanced encryption standard (AES) and encourages you to consider working with an FPGA.

This is the embedded processor design flow with FPGA. a: A C program is compiled for a softcore CPU, which is configured in an FPGA. b: To accelerate this C program, it is partitioned into a part for the software CPU, and a part that will be implemented as a hardware accelerator. The softcore CPU is configured together with the hardware accelerator in the FPGA.

Are you now ready to start a new data acquisition project? If so, read George Novacek’s article “Project Configuration Control” (p. 58), George Martin’s article “Software & Design File Organization” (p. 62), and Jeff Bachiochi’s article “Flowcharting Made Simple” (p. 66) before hitting your workbench. You’ll find their tips on project organization, planning, and implementation useful and immediately applicable.

Lastly, on behalf of the entire Circuit Cellar/Elektor team, I congratulate the winners of the DesignSpark chipKIT Challenge. Turn to page 32 to learn about Dean Boman’s First Prize-winning energy-monitoring system, as well as the other exceptional projects that placed at the top. The complete projects (abstracts, photos, schematic, and code) for all the winning entries are posted on the DesignSpark chipKIT Challenge website.