Skip navigation
All Places > Keysight Blogs > Insights Unlocked > Blog > 2017 > January
2017

The electronics industry is buzzing with the Internet of Things (IoT). One engineer described IoT as a vast conspiracy to put network connections on every object in the world—completely independent of whether it makes sense or not.

 

When we start connecting up all of these “things,” new system requirements creep in that may not be obvious. Your “thing” is no longer happily independent: it is part of a larger system. With connectivity comes new responsibility—in product design and on into the product’s useful life as a network citizen.

 

From a developer’s point of view, many IoT devices are “embedded designs.” This means they use microprocessors and software to implement functionality, often with an eye towards small compute footprint, just-enough processing power, lean software design and demanding cost targets. This is familiar territory for many design engineers, perhaps with the added requirement of providing a robust network connection. This is often going to be a wireless connection, be it Wi-Fi or some other common standard.

 

It’s unlikely that you are designing, defining or controlling that entire system. That raises a few key questions, starting with the issue of interoperability: How do you know that your device is going to be compatible with others on the network? Your device may also present a security risk to the network: How much protection can you build in? The assumedly wireless connection is both a source and receiver of RF emissions: How do you make sure it behaves properly in both roles?

 

Building on these topics, here are a few things to consider as you try to avoid the ills of this brave new world of everything connected.

 

Ensuring interoperability

Start by understanding the requirements of the larger system as they apply to your product. What other devices, compute resources, servers, etc., must you interoperate with? Because these systems are inherently complex and multivendor, all IoT devices need to “play well with others,” as described in Systems Computing Challenges in the Internet of Things. Creating a robust test strategy will help ensure that you have this covered. My prescription: Think like a systems engineer.

 

Managing potential security risks

Recent hacks have provided a much-needed wake-up call concerning IoT security. Low-cost devices may not have much data to protect, but they can be a giant security hole that tempts the bad guys with access to the rest of the network. Distributed denial-of-service (DDOS) attacks have been launched using simple devices such as netcams, and even lightbulbs have been hacked. (For some interesting thoughts on this topic, see IoT Problems Are about Psychology, Not Technology.)

 

Manufacturers that leave gaping security holes may face legal consequences: in early January, the Federal Trade Commission filed a complaint against D-Link for inadequate security measures in certain of its wireless routers and internet cameras.

 

You can start by plugging known holes in operating systems and other platforms. And, of course, don’t hardcode default passwords. Think through better ways to test for security problems: no, it isn’t easy—but it’s starting to feel mandatory. My prescription: Think like an IT engineer... or a hacker.

 

Preparing for interference

Your device probably uses one of many wireless connections. First, cover the basics of electromagnetic compatibility (EMC). Be sure the device passes relevant radiated-emission standards so it isn’t spewing RF that interferes with other devices. Also, ensure that your device isn’t susceptible to emissions from other sources.

 

It’s also important to consider the RF environment your device will live in—especially if unlicensed spectrum is being used, as in the case of Wi-Fi. The great thing about the unlicensed airwaves is that they’re free to everyone to use. The really bad thing about unlicensed spectrum is that everyone is using it and it’s a free-for-all. Thus, you’ll likely have to contend with other emitters in the same frequency span. See Chris Kelly’s post Preparing Your IoT Designs for the Interference of Things for some additional thoughts. My prescription: Think like an EMC engineer.

 

Wrapping up

My key point: IoT devices may seem familiar and comfortable to engineers who work with embedded systems—but this is a trap. Avoiding this trap starts with a shift in perspective, viewing IoT devices as citizens on a network that has critical requirements for systems, security and RF behavior. Without this shift, we will expose our products—and ultimately our companies—to customer dissatisfaction, customer returns and product liability.

You have been tasked with leading a team to go after this 5G business. Your strategic imperatives include success and leadership in 5G and you are an essential part of making it happen. Your management, your team, your C-suite, your board of directors, and perhaps even your family, are all counting on you to deliver.

 

No pressure. Just do it, right?

 

Before drawing up your battle plans and starting the assault, press pause and ask a few crucial questions. After almost 32 years in high tech, mostly in engineering management, I have found that one’s team often has a clear sense of the success-factors, enablers, and roadblocks on the road ahead. Check in and get their input. Even if you are two years down that road, there is still time to make course corrections.

 

Do you have the right background and expertise?

For many, 5G applications imply new technologies. This might mean designing for carrier frequencies and bandwidths that seem like black magic to most of your engineers. Have you considered all of the things they will have to learn or acquire? How many lessons will be acquired the hard way—by making mistakes and discovering, too late, that there will be a dreadful impact to your schedule or costs? How quickly can your team pivot when it needs to gain new or different expertise?

 

The 5th generation wireless technology may also require new business models. This could entail a foray into open-source software (or hardware) when your organization has never bothered with this sort of thing in the past. It might point you toward selling services or upgrades rather than making net-30 sales. How might you adjust your design team’s skills to suit this new paradigm?

 

Do you have the right tools?

Some of those new technical areas will require new tools for your team. Is it new hardware? Is it RF chambers of a different size? A new computer system focused on fast, efficient handling of much more data? Could you use EDA tools to reduce hardware turns? Which ones? And, with a nod to the preceding entry, how long will it take for your team to use them efficiently and effectively?

 

Are you closely connected to your key customers?

I am a fan of the agile software manifesto, especially the notion of putting designers close to their customers and providing rapid and frequent updates while embracing regular and rapid (if not capricious) changes in requirements.

 

In an industry driven by consumer fad, these elements are critical to all of your development activities—software, hardware and business. Without close ties to your most important customers (the ones with the most money, not the loudest voices) you will be too slow to address needs, anticipate changes, and respond.

 

Be sure you are talking to the right people in your key accounts. I once watched a major project fail because the team was getting its guidance from the wrong individuals. After significant investment on both sides, the ones who were really in charge appeared and unceremoniously shut down the entire program.

 

Is your timing consistent with theirs?

The recipe for a fabulously successful project is probably familiar to you: your project is synchronized with your two or three best lead customers and perfectly aligned with their project timing, and market demand is simultaneously growing. This magical combination is, to some extent, the result of luck—but we often make our own luck since the good lady “prefers the prepared mind.”

 

Do you have the support you need from your organization?

This is hardly unique to 5G, but we all need this reminder. I have occasionally been frustrated by subordinate managers who, after producing inadequate results, have said to me, “If only we would have had A or B…” to which my response was, “Why didn’t you ask?” I am embarrassed to admit I have made the same mistake myself.

 

Talk to your team and find out what they think would make the difference. They may be keenly aware of some bit of organizational support that will improve their chances of success; sometimes, it will be easy to get that help. Even if you can’t secure everything they want, the process will likely clear enough roadblocks to speed things along. (Keysight’s Sigi Gross offers a related perspective in point #3 of his 7/13/16 post.)

 

Where to go from here?

No pressure: just ask the right questions and act on the most actionable and efficacious answers. There is no substitute for the innovation associated with a well-prepared, customer-connected, and motivated team to overcome the other challenges.

 

Any other cautions, questions or stories you would care to share?