Modular delivers the adaptation required in the “Age of Accelerations”

February 6, 2018 Scott Nelson, Digi International

Thomas Friedman’s book “Thank You for Being Late” is a must-read for anyone working in technology and particularly those of us who design and build new offerings for the IoT. Friedman describes how change in our world is accelerating due to a confluence of events over the past decade, including:

  1. The introduction of the iPhone driving the social use of technology
  2. Moore’s Law driving the exponential cost reduction of technology bringing on the IoT
  3. IBM’s Watson introducing the world to AI on Jeopardy
  4. Mother Nature’s ever changing impact on the world’s agricultural productivity and human condition

Friedman’s thesis is simultaneously scary and inspiring. Several of these changes are progressive, even evolutionary in nature, but the combination is driving an acceleration of change.

I learned early in my training as a physicist that acceleration has exponential implications. Physics has trained me to model everything in my world: I look for mathematics to help me understand, forecast, and adapt to everything from how I run a triathlon (aerodynamics), to how to run a technology business (Monte Carlo simulations for ROI’s). So I was particularly drawn to Friedman’s recounting of his conversation with Google X’s Astro Teller on technology and human behavior. Teller described the challenge we humans now have with adapting to the cumulative power of technology with a figure on his white board.

[Figure 1 | Astro Teller’s Rate of Change and Adaptation curve]

We humans are still adapting to change, socially and policy-wise, at a modest linear rate. We don’t like change, but technology is accumulating power and value exponentially with each new advancement building upon and multiplying previous advancements.

Friedman’s analysis is about social and policy adaptation and he does an excellent job discussing how we might improve our ability to follow the technology curve with those tools. But as a product developer and business strategist, my problem can be summarized with a simple question: how do we keep up with accelerating change within the resource constraints of a business? How do we adapt to the accelerating rate of change?

Teller’s curve resonated with me, and I immediately thought about how technology companies, particularly industrial and medical companies, struggle with technology acceleration. Our product life cycles and development times are low-resolution steps of adaptation to the performance expectations driven by the technology change curve. Each new product moves performance in the right direction, but the rate of new product introductions has not increased commensurate with consumer expectations of technical performance. 

Our new products are a too slow, too coarse digitization of technology adaptation. Most of the time we take too long to develop new, higher performing products and fall below the curve (e.g., 2G/3G connectivity products in the age of higher capacity, faster 4G LTE). At times we see the technology curve, but the infrastructure of our application space is not able to afford the emerging technology and we release products ahead of their time (e.g. 4G LTE connectivity for IoT applications like asset monitoring). As a result, we spend much of our time in the marketplace with products that are out of sync with customer expectations; either we are too early/too expensive, or we are not using the state of the art, but the living obsolete.

The figure shows a connected industrial products example following the advancements in LTE that are driven primarily by consumer products. Note that as the technology curve accelerates exponentially, the time behind the curve – selling obsolete products – increases because the manufacturers cannot accelerate development (i.e. adapt) to maintain even a balance with customer expectations.

[Figure 2 | Ground up development cycles are too slow to follow the accelerating technology curve]

I recalled like curves during a similar technology change through which I personally navigated: the conversion of video displays from analog to digital (e.g. CRTs to LCDs).  My learning experience occurred in the application of head mounted displays to a wide range of applications, and I consulted with colleagues who were re-inventing avionics cockpit displays at the time and struggling with the same technology advancements. We struggled with the sophistication and refinement of human visual perception in the context of this new digital imaging technology.

It was from these digital display specialists that I first learned of anti-aliasing. I know, I am getting down into the weeds here, but stay with me.  The challenge at the time was drawing smooth, analog lines on a display with digital pixels. The infamous “jagged line” was irritating to human viewers and became a key metric of display performance. Pixel density was, of course, an obvious solution, but display designers could not just reduce pixel size to whatever was needed to avoid the “jaggies.” LCDs (Liquid Crystal Displays), the dominant digital display technology of the time, were limited in resolution and production similar to how semiconductors were limited in each step of Moore’s Law. So after increasing pixel density to its manufacturable limit, the tool that display builders brought to bear was “anti-aliasing.” In layman’s terms, they blurred the pixels in such a way that the line appears to become smoother and more accurate than its analog counterpart.

[Figure 3 | Smaller pixel sizes and anti-aliasing helped early digital display designers reduce viewer-irritating jagged edges on image edges.]

This anti-aliasing story of digital displays provides insight into our “adapting to the technology curve” conundrum. Product management/development have responded to the technology curve with the “higher resolution” approach of display design. They first respond to technology acceleration by increasing resolution -- developing and releasing products faster, but this is very expensive. Companies need more engineers and designers to go faster and they start over more quickly so the burn rate in R&D increases in a sustained manner raising the fixed cost of the business.  Without Apple’s gross margins or product volumes, this can break the business.

So the question is, how do we take smaller steps and blur the line? The answer for IoT builders is modular architecture. Modules and modular architecture have been around for a long time, but the level of penetration in IoT offerings must increase if companies are going to stay with the technology curve and build affordable products that customers want. 

Cellular modems, for example, have been in use in industrial applications for many years, but carrier certifications of products are expensive and time consuming slowing down the product development cycle. Recently, end-device-certified modules have entered the market helping industrial and medical equipment companies reduce this part of the cycle. This is a step in the right direction, but it is not enough. 

IoT architects have to look more broadly than just certifications when considering modules and product line architecture. The IoT ecosystem is constructed mostly on software and, more than any time in our history, transforms based on the speed of learning – both human and machine. Modules and modular architectures offer the opportunity to address this technology change and the business performance challenges it creates. Modules offer manufacturers three important tools to both follow and smooth out their adaptation vs. technology curves:

1. Faster regulatory and standards compliance shortens the cycle

One of the challenges of IoT right now is the proliferation and rapid change of both regulations and standards. Security and privacy regulations are changing rapidly as more and more devices go online.  Communications standards like LTE are branching and accelerating in the telecommunication industry’s adaptation to market needs. Modules reduce the development time and cost of complying with changing standards, particularly when pre-certifications are included. Modules can also pre-enable compliance with regulations, e.g. ISO 13485 in medical applications, as well as standards like FCC Classes and PTCRB in RF and cellular applications. Security patches and upgrades are often done over-the-air (OTA), but modular architectures enable hardware implemented upgrades to equipment without full reconstruction or replacement.

2. Aggregating technical and customer support reduces the cost

One of hidden challenges of IoT is customer service and technical support costs.  As developers integrate new technologies and additional parts of the ecosystem, supporting customers becomes more complex and expensive for each new product experience. Customer and technical support costs don’t just scale with revenue, they can out run it and reduce margins as B2B sales result in B2C support calls.

A modular product architecture allows the Product Manager to better match product features with segments, i.e. carry more offerings better matched to unique segment needs, while leveraging technical support and maintenance costs aggregated at the function level through modules.  Modular architectures allow scalable revenue with improved margins because support costs do not have to scale with revenue.

3. Leveraging the power of software blurs the line – extends performance of each step]

Modules are an integration of hardware and software to deliver a functional block of the product architecture. As such, they allow developers the opportunity to blur the lines of each step in the performance curve with software enhancements. A given hardware module, particularly computing modules, can have multiple software images and cumulative software value. Module manufacturers also have to adapt and leverage software to extend the capabilities of their modules. Digi’s Xbee3 RF and cellular modules, for example, now have programmability that allow additional business or data logic to be programmed at the point of origin of the data. 

The life cycle of a modular architecture, therefore, is extended around the hardware cycle and allows the business to follow changes with more rapid software upgrades. The curve below shows how modular software can blur the product development cycle and keep a given hardware iteration in line with performance expectations longer.

Cumulative software advancement built within a modular hardware architecture blurs the gap between development cycles and technology expectations in the IoT.

[Figure 4 | Cumulative software advancement built within a modular hardware architecture blurs the gap between development cycles and technology expectations in the IoT.]

The “Age of Accelerations” presents daunting challenges for society and industry alike. IoT manufacturers know that they must build smart products to keep up with technology acceleration. New product functions and features make them effective in their application within the IoT, but smart product companies have to leverage modular architecture to keep up with the accelerating customer expectation curve driven by Moore’s Law and consumer electronics companies like Apple, Amazon and Samsung. Keeping up with technology using traditional product management and development is not sustainable. Modular architectures allow manufacturers to increase their pace and application of new products while “blurring the line” of performance of each step. Modules give them the tools to adapt.

Scott Nelson is Vice President of Product at Digi International.

Previous Article
Breker Verification Systems joins the ESD Alliance

Breker introduced a graph-based approach to test case generation that has formed the basis of the Accellera...

Next Article
i.MX 7ULP ARM Cortex-A7 Processor powers the PicoCORE MX7ULP COM
i.MX 7ULP ARM Cortex-A7 Processor powers the PicoCORE MX7ULP COM

NXP ARM Cortex Apps Processor is behind the COM board from F&S Elektronik Systeme GmbH


Follow our coverage of hardware-related design topics with the Hardware edition of our Embedded Daily newsletter.

Subscribed! Look for 1st copy soon.
Error - something went wrong!