Contents
Internet of Things Handbook
04 Editorial Note Engineering connections.
06 Improving plant operations with low-cost IIoT power-use monitoring IIoT monitoring can lead to energy savings and reveal operational inefficiencies through detailed equipment usage data.
09 Securing devices for the IoT: IEC 62443, SESIP, and PSA
Interrelated standard and requirements provide a comprehensive framework for developing secure IoT devices.
12 Power consumption for IoT modules: Protocols matter
Time equals power when transmitting data to and from NB-IoT and LTE-M devices. How you use communication protocols can affect power use.
14 Running IoT through the skies
Promising Non-Terrestrial Networks offer a costeffective answer to overcoming global communication barriers in IoT and industry.
16 Matter 1.2 is Here: What does that mean for the smart home?
Support for nine new devise types and improvements in interoperability, user experience, and certification highlight the latest standard.
19 What are the constituents of Matter?
Matter’s constituents include a modular software stack, plus bridges, controllers border routers, security, authentication, and cloud connectivity.
April 2024
24 Securing devices for the IoT: Minimize the attack surface
Meet the growing security challenges of IoT devices and cloud computing by examining common attack vectors and understanding management and protection solutions.
27 What can designers make with Matter?
Matter provides designers with a unified open-source application layer to speed the development of smart IoT devices.
30 Securing devices for the IoT: Firmware, Software and OTA
Open-source standards and industry frameworks are revolutionizing OTA to ensure secure and efficient firmware and software management.
32 Securing devices for the IoT: managing memory
Developers must navigate the complexities of managing memory in languages prevalent in IoT development to avoid common security vulnerabilities.
34 How does Matter support multiple fabrics?
There are several best practices and solutions availble to address the technical challenges involved in supporting multiple fabrics within the Matter ecosystem.
36 When to use standalone or MCUhosted matter platforms
There’s no simple answer to the question of when to use standalone or MCU-hosted Matter platforms, but there is a lot to consider.
EDITORIAL
VP, Editorial Director Paul J. Heney pheney@wtwhmedia.com @wtwh_paulheney
Editor In-Chief Aimee Kalnoskas akalnoskas@wtwhmedia.com @eeworld_aimee
Senior Technical Editor Martin Rowe mrowe@wtwhmedia.com @measurementblue
Associate Editor Emma Lutjen elutjen@wtwhmedia.com
Managing Editor, EV Engineeering Michelle Froese mfroese@wtwhmedia.com
Design World
CREATIVE SERVICES & PRINT PRODUCTION
VP, Creative Services
Matthew Claney mclaney@wtwhmedia.com @wtwh_designer
Art Director Allison Washko awashko@wtwhmedia.com @wtwh_allison
Senior Graphic Designer
Mariel Evans mevans@wtwhmedia.com @wtwh_mariel
Graphic Designer
Shannon Pipik mevans@wtwhmedia.com
Director, Audience Development
Bruce Sprague bsprague@wtwhmedia.com
MARKETING
VP, Digital Marketing
Virginia Goulding vgoulding@wtwhmedia.com @wtwh_virginia
Digital Marketing Coordinator
Francesca Barrett fbarrett@wtwhmedia.com @Francesca_WTWH
Digital Design Manager Samantha King sking@wtwhmedia.com
Marketing Graphic Designer Hannah Bragg hbragg@wtwhmedia.com
Marketing Graphic Designer Nicole Johnson njohnson@wtwhmedia.com
Webinar Manager Matt Boblett mboblett@wtwhmedia.com
Webinar Coordinator Halle Sibly hkirsh@wtwhmedia.com
ONLINE DEVELOPMENT & PRODUCTION
Web Development Manager B. David Miyares dmiyares@wtwhmedia.com @wtwh_WebDave
Senior Digital Media Manager Patrick Curran pcurran@wtwhmedia.com @wtwhseopatrick
VIDEOGRAPHY SERVICES
Videographer Cole Kistler cole@wtwhmedia.com
Videographer Kara Singleton ksingleton@wtwhmedia.com
PRODUCTION SERVICES
Customer Service Manager
Stephanie Hulett shulett@wtwhmedia.com
Customer Service Representative
Tracy Powers tpowers@wtwhmedia.com
Customer Service Representative
JoAnn Martin jmartin@wtwhmedia.com
Customer Service Representative Renee Massey-Linston renee@wtwhmedia.com
Customer Service Representative Trinidy Longgood tlonggood@wtwhmedia.com
FINANCE
Controller
Brian Korsberg bkorsberg@wtwhmedia.com
Accounts Receivable Specialist
Jamila Milton jmilton@wtwhmedia.com
WTWH Media, LLC
1111 Superior Ave., Suite 2600
Cleveland, OH 44114
Ph: 888.543.2447
FAX: 888.543.2447
2013- 2017
DESIGN WORLD does not pass judgment on subjects of controversy nor enter into dispute with or between any individuals or organizations. DESIGN WORLD is also an independent forum for the expression of opinions relevant to industry issues. Letters to the editor and by-lined articles express the views of the author and not necessarily of the publisher or the publication. Every effort is made to provide accurate information; however, publisher assumes no responsibility for accuracy of submitted advertising and editorial information. Non-commissioned articles and news releases cannot be acknowledged. Unsolicited materials cannot be returned nor will this organization assume responsibility for their care.
DESIGN WORLD does not endorse any products, programs or services of advertisers or editorial contributors. Copyright© 2024 by WTWH Media, LLC. No part of this publication may be reproduced in any form or by any means, electronic or mechanical, or by recording, or by any information storage or retrieval system, without written permission from the publisher.
SUBSCRIPTION RATES: Free and controlled circulation to qualified subscribers. Non-qualified persons may subscribe at the following rates: U.S. and possessions: 1 year: $125; 2 years: $200; 3 years: $275; Canadian and foreign, 1 year: $195; only US funds are accepted. Single copies $15 each. Subscriptions are prepaid, and check or money orders only.
SUBSCRIBER SERVICES: To order a subscription or change your address, please email: designworld@omeda.com, or visit
Remote wireless devices connected to the Industrial Internet of Things (IIoT) run on Tadiran bobbin-type LiSOCl2 batteries.
Our batteries offer a winning combination: a patented hybrid layer capacitor (HLC) that delivers the high pulses required for two-way wireless communications; the widest temperature range of all; and the lowest self-discharge rate (0.7% per year), enabling our cells to last up to 4 times longer than the competition.
Looking to have your remote wireless device complete a 40-year marathon? Then team up with Tadiran batteries that last a lifetime.
Engineering connections
REMEMBER
when the estimated number of connected devices in 2005 was around six billion, followed about five years later with the acronym “IoT” achieving buzzword/hype status? Now fast forward to next year, when that number is expected to skyrocket to a staggering 75 billion, or roughly nine devices per person on the planet. That's a lot of devices — and a lot of design.
The expectations around the Internet of Things seem to rise exponentially with each new iteration of a device, platform, or communications technology. Can it be faster, smaller, and cheaper? Can it be simple to implement and integrate? Oh, and by the way, does it have bulletproof security that's transparent to the user? Tall orders, to say the least.
One of the biggest hurdles is ensuring secure authentication and unique identification for each connected IoT device. Without that foundation of trusted communication, the whole system falls apart. And even once you've got that locked down, integrating all the data and devices with regular business applications and processes remains a major challenge.
Then there's the connectivity issues — maintaining reliable, seamless wireless links for IoT gadgets, even in tough environments? That's no easy task. On top of that, you've got to protect all that IoT data from cyber threats and ensure user privacy is airtight. The lack of common standards for IoT devices and protocols just compounds the compatibility and interoperability nightmares.
Many of these connected devices also have pretty weak or non-existent
authentication, leaving them vulnerable to attacks. Securing the embedded software and firmware in those resourceconstrained IoT products? That's a whole other level of complexity. Scaling up IoT systems to handle growing numbers of devices and mountains of data without performance degradation? That's a major challenge too.
Finally, (maybe), the rise of Artificial Intelligence (AI) is driving the mainstream adoption of IoT technology, but also introducing new design complexities that need to be addressed.
Despite these and other daunting obstacles, engineers continue to push the boundaries of what's possible in the IoT space. As the number of connected devices skyrockets, the challenges will only become more complex. But talented minds are tackling these challenges with innovative new components and tools, while reaching for resources like this Handbook...and maybe some AI.
Improving plant operations with low-cost IIoT power-use monitoring
IIoT monitoring can lead to energy savings and reveal operational inefficiencies through detailed equipment usage data. By James Wiczer
IIOT can provide costeffective and userfriendly solutions for monitoring various operational in-plant parameters. This article focuses on the benefits of using IIoT instrumentation to monitor the power usage and relative health of diverse manufacturing equipment utilization and operational details. IIoT technologies can now leverage existing computers, web browsers, and network connections to deliver up-to-date and relevant information to key personnel within a facility. In abnormal conditions, real-time alerts can be automatically sent as email or text messages. Implementing these solutions can provide the necessary insights to reduce power consumption, improve process efficiency, lower maintenance expenses, and decrease labor and material waste.
Compared to dedicated monitoring solutions or programmingintensive DIY approaches, today's IIoT power monitoring solutions are fairly affordable. They provide a simple solution for power measurement, data capture, and analysis — and can be implemented by in-house staff. In the past five years, hardware and software advancements have resulted in IIoT solutions with significantly improved capabilities and reduced costs. As a
result, a new class of inexpensive, complete end-to-end monitoring solutions is now available that is practical for both large and small facilities. For example, a complete, basic IIoT power monitoring solution can cost less than $1500, enabling relatively low power-consuming equipment to be fully monitored 24/7/365 with a 1-second measurement resolution. These solutions utilize core technologies such as singleboard computers, wired and wireless networking, software visualization tools, sensor fusion, multiple sensors, and measurement interface technologies.
In addition to identifying the power consumed by key pieces of equipment or production processes, an indirect history of production activity is created. This provides real-time insights into how the equipment is being used and correlates directly with the equipment's contribution to production, down to the specific energy cost for each component or batch that the equipment processes. Such a level of detail cannot be acquired by reviewing an all-inclusive utility bill.
Even in cases where the actual annual cost of electricity needed to operate a machine is less than $10,000 a year, it can
make sense to monitor power use because of the impact of the collected information. Insights into when and how the equipment is used can quickly offset the monitoring solution investment. This typically reveals details such as equipment availability and whether the equipment runs at full speed 95% of the workday or runs mostly at idle speed. Power-use and run-time information can also be used to help predict maintenance needs. This is an especially useful feature for avoiding the unexpected downtime of key pieces of equipment that could cause operational disruptions.
Revenue-grade and non-revenuegrade electricity measurements
There are many ways to measure electrical energy consumed by a piece of equipment or industrial process, but some methods are costly, challenging, and disruptive to install. One way to consider the various power-use measurement technologies is by grouping measurement technologies into two broad categories — revenue-grade measurements and non-revenue-grade measurements.
Electric utility companies use revenue-grade measurements to bill customers for their energy use or can be used by customers to
verify that their bills are consistent with their actual power use.
Revenue-grade measurements are required to comply with certain levels of accuracy that are defined by ANSI C12 and IEC 62053 family of standards. These standards mandate accuracies within 0.2% to 2.0% of the true power use depending on the local requirement and the specifics of the customer's agreement with the local utility. Generally, the cost and installation complexity of revenue-grade power monitoring makes deploying on individual machines or processes impractical.
Non-revenue-grade measurement can be much less costly to acquire and easier to install but may provide less accurate measurements. Non-revenue grade measurements may be accurate only within 2% to 5% of the true power use, making them unsuitable for a billing function. They, however, may be precise and repeatable to within 1%, making them a very useful way to track operations and approximate power consumption. Solutions become very practical when inexpensive measurement technologies are combined with IoT technologies, individual machines, or process monitoring. Another advantage is that these systems can typically be installed without a plant shutdown or complex network interfacing.
Interpreting simple on/off poweruse measurements
Often, there is much to gain with the simplest power-use review. You don't have to be an expert data analyst to discover significant insights into processes and to identify ways to save money on electricity using a simple on/off analysis. A brief review of a power on/power off chart may indicate savings from better equipment utilization to allow for a reduction in wasted power during a non-production period. For example, is the air compressor running on a Sunday when no one is in the plant? Was it left powered on at the end of a shift? In many facilities, the cost of running an air compressor can represent 10% to 20% of the total monthly electric bill, so running the compressor when there is no production
may not be necessary. Excessive compressor run times may indicate an air leak. We know from experience that such a simple on/off analysis will often reveal surprising information about plant energy usage. Armed with such data, plant managers can make intentional decisions about equipment use and be alerted to unexpected events.
IIoT technologies can easily capture insights from power variations
By analyzing variations in power use, hidden patterns and anomalies that may cause production interruptions and product quality variations can be uncovered. IIoT technologies enable the connection of raw measured data with data analysis algorithms already integrated into the IIoT computation hardware. This often provides greater analytical depth compared to discrete power metering solutions. Additionally, IIoT technologies offer a range of valuable data visualization tools for gaining comprehensive insights.
Correlating power measurements with other related events
In many facilities, critical pieces of equipment are interconnected in some way. Fully understanding the significance of power use measurements for one piece of equipment may require analyzing sensor measurements from other equipment. In fact, crucial production patterns may be identified only by comprehending the synergy between multiple pieces of equipment through synchronized measurements facilitated by IIoT.
For instance, by connecting timesynchronized power measurements from a vacuum pump with vacuum pressure changes in other areas of the factory floor, valuable insights can be gained regarding power waste and the occasional increase in defective products, as shown in Figure 1.
What to measure first
In many manufacturing operations, there are several places where power monitoring could be useful, but the question often becomes, "Where do we start." In some cases, the financial return on acquiring and installing an inexpensive IIoT measurement solution may justify the costs in just one or two months.
So, instead of focusing on an awkward ROI calculation, select a project that may be important to corporate goals, like removing production bottlenecks or projects with a potential for substantial savings.
Be strategic and select the equipment or production process to provide the most insights and the fastest potential return on investment. Experience has shown there are several high payoff areas. Since power-use measurements can not only result in power savings, knowing equipment use details with one-second resolution can often illuminate issues related to workflow, equipment utilization, labor allocation, material resource use issues, and proactive maintenance. Sometimes, the value of this information will not become apparent in an ROI calculation until after it has been acquired and reviewed or combined with other data measured at the same time. Measurements with good time resolution (i.e., one second) are necessary to grasp many manufacturing operations.
Monitoring equipment or processes with high energy intensity, such as large motors and heating and cooling processes, is also important. Figure 2 shows the placement of a complete IIoT power-use monitoring system squeezed into available space on the power supply of an induction furnace tilting and pouring (Figure 3). Monitoring powerhungry equipment that uses large amounts of power may provide significant and rapid financial returns since even a small change to operational procedures could result in substantial power savings.
Other potential opportunities for finding power savings by monitoring include focusing on equipment with human-operated controls requiring subjective decisions in inproduction settings. These processes often have large variations in activity and electricity use that can be quickly identified and quantified with power measurement data.
Consider improved, more detailed monitoring of automated equipment that runs continuously without regard to the lack of production activities in a plant. For example, pumps often have pressure setpoints but may not know it's a weekend or holiday when no production processes
Figure 3. An induction furnace used for metal casting, tilting, and power.
are occurring anywhere in the plant. This automated equipment may continue to run if only to fill header pipes with air and feed the leaks. Figure 4 shows data collected from an IIoT monitoring system simultaneously monitoring the electric power driving an air compressor and the pressure in the header pipes. When the power driving the air compressor is turned off, as shown in the lower graph, the pressure in the header pipes gradually decreases, as shown in the upper graph. A detailed analysis of these two graphs and some information about the air compressor's capacity can be used to estimate the magnitude of air leaks in the facility.
Power-use measurements enhance operational awareness
In addition to utilizing power measurements to track electric power consumption, these exact measurements can be used to track other resource usage, including labor, equipment, and material supplies. IIoT solutions are particularly adept at providing real-time email and mobile phone text messages, instantly alerting key staff to outof-normal conditions. IIoT systems include the essential elements to examine real-time raw measurement data and communicate
alarm conditions based on the user's preset alarm threshold criteria.
These IIoT power monitoring solutions can reduce the risk of equipment failure through timely alert messages of out-ofnormal conditions.
At times, power monitoring can even identify rather specialized machine operator errors. For example, some pieces of equipment require full-time machine operators to work at the machine when the power levels are at any level other than zero. Associating a non-zero power use with operator labor provides a simple way to determine the hours and minutes of labor resources associated with part production.
In another situation, understanding the measured power vs. time profile of key equipment can be helpful in better understanding production bottlenecks and the need for maintenance. Consider the example of a furnace making molten metal
to be subsequently poured into molds elsewhere in the facility. This molten metal resource is essential to production and may pace daily production. Understanding the detailed daily time profile when the furnace is creating molten metal and when it is in idle mode may be very insightful in coordinating production resources.
Finally, better understanding asset utilization profiles by analyzing poweruse data can help determine the need for additional equipment or help identify which equipment is not utilized enough to justify the annual maintenance costs. This can either validate the need for capital expenditure or highlight equipment capacity that is not fully utilized.
Conclusion
Measuring power use at the machine or process level often yields compelling insights into not only energy costs but also
the header pipes. When the power driving the air compressor is turned off, as shown in the lower graph, the pressure in the header pipes gradually decreases, as shown in the upper graph. A detailed analysis of these two graphs and some information about the air compressor's capacity can be used to estimate the magnitude of air leaks in the facility
equipment utilization, process variations, and resource allocation. This knowledge can provide dramatic returns through reduced electricity costs, proactive maintenance, improved production efficiency, and more consistent quality.
Choosing non-revenue-grade power monitoring equipment utilizing IIoT technologies reduces the cost barriers of acquiring power-use data for critical equipment, making new and often significant insights into production processes clear. With a good selection of IIoT power-use measurement equipment, operators, plant engineers, and managers will have easy, on-demand access to complete 24/7/365 information, including automatic emails and text messages reporting critical out-of-normal status conditions to key staff.
Securing devices for the IoT: IEC 62443, SESIP, and PSA
Interrelated standard and requirements provide a comprehensive framework for developing secure IoT devices.
By Jeff ShepardTHEInternational Electrotechnical Commission (IEC) 62443 series of standards is focused on security for Industrial Automation and Control Systems (IACS); the Security Evaluation Standard for IoT Platforms (SESIP) provides a method for trustworthy assessment of the security IoT platforms, including the industrial IoT (IIoT), and Platform Security Architecture (PSA) certification requires strict adherence to the defined architecture.
While these standards are developed and maintained independently, they are also somewhat interrelated. This article reviews the IoT standards and their interrelationships.
The IEC-62443 series provides a systematic approach to assessing the need for cybersecurity in industrial systems. It considers factors from initial risk assessments to ongoing operations and defines five security levels (SLs) from SL0 (no security) to SL4 (resistant against nation-state attacks). SL3 and SL4 require hardware-based security. Discrete ICs for hardware security are temper-resistant and provide higher security levels than software-based solutions (Figure 1).
The various sections of the IEC 62443 standard can be split into four general categories (Figure 2):
• General documents introduce basic concepts of industrial security and provide an overview of related processes.
• Policies & procedures documents review the importance of proper security policies and suggest several useful procedures to be followed.
• System documents review essential considerations for integrating security into IACS at the system level.
• Components documents detail the security requirements for individual components and sub-systems that comprise an IACS.
SESIP
SESIP is based on the Common Criteria methodology (ISO 15408-3) and defines a standard for trustworthiness assessment of the security of the IoT platforms. SESIP is focused on security for individual IoT nodes. It defines a platform security architecture (PSA), security assurance requirements (SARs), and security functional requirements (SFRs). It includes some flexibility for implementation. For example, a subset of the SFRs may be identified for a specific application that requires higher assurance.
SESIP platforms, also called profiles, are being developed for specific use cases like
ARM PSA L1 and IEC 62443. SESIP includes five assurance levels from SESIP1 to SESIP5 (Figure 3):
• SESIP1 is a self-assessment without third-party validation.
• SESIP2 adds black-box penetration testing and vulnerability testing.
• SESIP3 uses a more detailed white-box vulnerability analysis and penetration testing, including a source code review.
• SESIP4 is for re-using senior officials’ group information systems security (SOG-IS) certified platforms or subsystems by licensed third-party evaluation laboratories.
• SESIP5 adds that all the standard Common Criteria assurance components must be included in the assessment, specifically requiring
AVA_VAN.5 advanced methodical vulnerability analysis.
PSA
PSA specifications were created by ARM, a co-founder of the PSA-Certified organization.
While SESIP allows some flexibility in implementation, PSA certification requires strict adherence to the platform’s security functional requirements. A key element in PSA chip-based security is the PSA root of trust (PSA-RoT).
The PSA-RoT is a secure processing environment based on a Protection Profile and an independent evaluation. It combines trusted hardware like crypto accelerators, private vital stores, and memory with firmware separated from the system software using hardware isolation. To gain
IoT Devices.
‘PSA Certified’ status, the PSA-RoT must be subjected to trustworthy testing by an independent testing laboratory.
The three levels of PSA certification include:
• PSA Certified Level 1 — focuses on 50 requirements split into three sections for chip vendors, software platforms, and device manufacturers.
PSA Certified Level 1 maps to the requirements of NISTIR 8259A (see references) and ETSI EN 303 645 Cybersecurity Standard for Consumer
• PSA Certified Level 2 — protection from scalable software attacks adds a 25-day independent evaluation of the chip’s PSA-RoT using the published Protection Profile, Evaluation Methodology, and Attack Methods.
• PSA Certified Level 3 — protection from substantial physical and software attacks adds deeper security testing of PSA-RoT assets, including side-channel attack protection for cryptographic keys.
Summary
Securing devices for the IoT and IIoT is complex. Fortunately, several standards are available to guide the development of secure and robust IoT devices. Depending on the application and circumstances, developers can turn to IEC 62443, SESIP, and PSA for the requirements of designing secure IoT devices.
References
How to implement IEC 62443, Infineon Level 3 PSA Certification – What it is and Why it Matters, Silicon Labs
SESIP: An optimized security evaluation methodology, designed for IoT devices. Global Platform
SESIP System-Level Security for IoT Applications, NXP
Structuring the ISA/IEC 62443 Standards, ISA Global Cybersecurity Alliance
What is NISTIR 8259A?, Firmalyzer
What Is the PSA Certified IoT Security Framework?, PSA Certified
Power consumption for IoT modules: protocols matter
Time equals power when transmitting data to and from NB-IoT and LTE-M devices. How you use communication protocols can affect power use. By Martin Rowe
WHENdesigning an IoT device using a cellular wireless module, there are many factors to consider in minimizing power consumption. Data sheets can provide guidance on power supply design, module placement, and connections; that will get you through the hardware design of your product, but it’s not the whole story. How you use the module makes a difference as well.
How you use the module, meaning that protocols make a difference in power consumption. Your goal is to keep the module operating at the lowest possible power level for the maximum amount of time while still achieving the desired performance.
The protocols you use and how you implement them at the application level make a difference in power use. Some power consumption is inevitable regardless of module or protocol because all modules must first connect to the cellular network; they all need to go through the cellular protocol stack. All modules have a boot time and must physically scan for a network in the bands of interest. That time is generally fixed. Once a module is registered on the network, you’re in the application space where your choices make a difference.
Suppose you’ve designed a module into a utility meter. You might use a “fire and forget” protocol that minimizes power consumption by simply sending a meter reading and shutting down the module. That’s the
lowest power (and cost) way to send a message. If a reading gets lost, there’s always tomorrow. To accomplish this exchange, simply send a User Datagram Protocol (UDP), Message Queue Telemetry Transport for sensor networks (MQTT-SN), or Constrained Application Protocol (CoAP) message. The application can either shut down the module or use the 3GPP power-saving mode (PSM).
When the application requires an acknowledgment from a server, the module needs to wait for a downlink message. During this time, the radio is still connected, waiting for the ACK message. Some modules use NBIoT because of low power, but then use protocols that take time and use unnecessary power; we call those chatty protocols.
1. A typical CoAP
process. (Image: Constrained Application Protocol for Internet of Things)
Experimental results
As an experiment, we tried using Cat-M1 and NB-IoT modules to send messages of 150 bytes. When sending that amount of data, the NB-IoT module used less power than the Cat-M1 module. Cat-M1 gets more efficient as the number of bytes increases. At 500 bytes and up, low-data-rate protocols mean your transmitter is on for longer. Cat-M1 modules support ten times the data rate as NB-IoT, and thus are on for less time for a given amount of data.
With the NB-IoT protocol stack, when it re-attaches to the network, the attached message and the customer’s message are all part of the same transmission. Cat-M1 does not yet have these optimizations, and the application messages must travel over the User Data Plane. This is less efficient than sending
messages over the Control Data Plane for shorter messages, say less than 200 bytes. The power efficiency crossover seems to occur somewhere between 150 and 200 bytes.
If you look at Lightweight M2M (LwM2M), you’ll see that its protocol is message heavy. Modules must negotiate lots of information with the host. The good news is it has lots of features. The dayto-day operation of an IoT device might not need LwM2M. It can use MQTT-SN or CoAP instead. Figure 1 shows the typical CoAP protocol sequence. Module users can change protocols depending on the application and should take advantage of that option. Keep that in mind when developing application software for your device. Protocol stack libraries are available for that purpose. Clients can be built into modules; you don’t need to develop your own client. There’s no cost in switching protocols. It’s just a matter of sending a few TCP or UDP packets.
3GPP power saving
3GPP specifies power-saving modes. For example, a module could go into listening mode for a specified amount of time before going back into sleep mode, called Extended Discontinuous Reception (eDRX). A module’s powersaving features depend on its chipset, although most implement Release 13/ Release 14 features. In listening mode, a chipset might only consume microamps of current. Some modules don’t need to fully boot when they wake up from sleep mode. Other modules need to boot, which can take four or five seconds when the module is powered but not sending useful data.
The difference in power consumption from transmit to receive may depend on distance. A short distance to a base station means less transmit power. Receive current could be less than 100 mA but transmit current could be much higher. It depends on the distance to the base. The network defines the transmit power needed by the remote device. For the receiver, the network will determine how often (duty
when transmitting than when receiving, but the power consumption when transmitting will differ depending on the distance to the base station.
cycle/C-DRX) the module will listen to the network’s signaling. Figure 2 compares a typical transmit and receive current for a wireless module.
As you can see, the protocols you use can make a difference in your IoT device’s power consumption. Choose your protocols based on data transfer rates and size. The right choices result in lower power use and lower power costs for the final device user
Running IoT through the skies
Promising Non-Terrestrial Networks offer a costeffective answer to overcoming global communication barriers in IoT and industry.
By Dana Cohen Mizrahi, Sony Semiconductor IsraelNON-TERRESTRIAL
network (NTN) connectivity is making its way into IoT chipsets, enabling connected devices and installations to be deployed anywhere. Some devices are outfitted with stand-alone chips that can only connect to satellites, while others use hybrid chipsets that support terrestrial and non-terrestrial connectivity.
Why NTN?
Legacy cellular network deployments cover over 80% of the population but less than 40% of land and less than 20% of Earth. Satellite connectivity has been used for years to provide ubiquitous coverage. However, its high cost has limited use in specific scenarios, such as TV and broadcasting. Satellite connectivity has always been a last resort alternative to terrestrial networks in the IoT domain.
In recent years, the cost of NTN solutions has dropped. As a result, it is economically feasible to use NTN communication for IoT devices and start to answer the need for “communication everywhere.” NTN has developed into a communication channel of choice in various scenarios, including that of an
emergency communication network or offloading traffic from the terrestrial networks during peak times. Industries such as automotive, energy infrastructure, agriculture, maritime, and railway can enjoy global communication.
Mountain climbers, for example, often move from connected areas to areas outside of cellular coverage. Extreme sports require a connected device in an emergency, and hybrid cellular/NTN-connected devices can help in those situations.
Remote installations are also in need of satellite IoT. Maritime shipments, offshore oil rigs, and trains are typically outside cellular range. NTN can provide a reliable connection for monitoring and controlling these installations, even in remote locations.
Over the past few years, we have seen several new players, many developing their technology. 3GPP developed standards to enable the market to grow for broadband NTN and IoT-NTN- LTE-M & NB-IoT. 3GPP has started with study items in releases 15 and 16 and included a work item starting in release 17.
Looking at satellite IoT trends
According to IoT Analytics, the total number of satellite IoT subscribers reached 5.1 million in 2021. It is forecast to grow at a 22% CAGR between 2021 and 2026 and is expected to reach 13.5 million subscribers by 2026.
Non-terrestrial networks (NTN) are comprised of satellites — Geostationary Equatorial Orbit (GEO), Medium-Earth Orbit (MEO), and Low-Earth Orbit (LEO) — as well as high-altitude platform systems (HAPS), which include unmanned airships or airplanes above 20 km, and unmanned aerial systems (UAS) or drones.
All satellite systems that provide IoT/M2M communication services are based on either GEO or LEO satellites. GEO constellations are more associated with legacy satellite operators, while a combination of established and emerging satellite operators provides LEO satellite services.
LEO constellations are quickly becoming the preferred option for satellite operators that offer IoT/M2M connectivity services. It provides far quicker and cheaper network building and deployment, a better link budget, and a higher availability of orbit paths. Additionally, LEO offers better latency than GEO due to the shorter distance to Earth (Figure 1).
In contrast, GEO has the advantage of providing a much more extensive coverage area, which also means it requires fewer satellites to deliver global coverage. GEO satellites appear stationary when viewed from a fixed point on the ground and rotate at the same speed and direction as the Earth. Ground antennas can connect to the satellite by pointing at it without tracking its position. This helps make using GEO technology relatively inexpensive, while at the same time, these satellites have a much longer lifetime.
The round-trip time for a GEO satellite is approximately 600–800 ms, while data moves back and forth to a LEO satellite in the range of 30–50 ms. This would make it seem like LEO constellations are better
suited to real-time applications. However, today’s LEO satellite IoT networks have a limited number of satellites in orbit. They cannot provide continuous connectivity to the entire world but can provide somewhat intermittent, periodic coverage. This means that data points can only be taken from IoT devices a few times every 24 hours as the satellites move around Earth. As a result, the latent GEO constellations are often better suited to near real-time applications than LEO constellations.
The future of IoT NTN
The future of NTN looks promising as the technology continues to evolve and improve. New technologies, such as lowpower radio and advanced modulation schemes, are being developed to improve the efficiency and reliability of NTN connections. Additionally, companies are working on reducing the costs of launching and maintaining LEO satellites, making it more accessible for businesses of all sizes to use NTN for their IoT applications.
NTN connectivity is an increasingly important technology for connecting devices in remote and hard-to-reach areas. As the technology continues to improve and costs decrease, we can expect to see more and more devices and applications utilizing NTN connectivity in the future.
Matter 1.2 is here: what does that mean for the smart home?
Support for nine new device types and improvements in interoperability, user experience, and certification highlight the latest standard.
By Rob AlexanderTHE rapid evolution and expansion of the IoT that has occurred over the course of the last decade has resulted in smart devices becoming a pervasive part of our everyday lives. Thousands of smart home products exist on the market today, and everything from our light switches to our vacuum cleaners now has the potential to make our lives easier via wireless, network-enabled automation.
But explosion of the smart home industry has not been
without challenges for both consumers and product developers. Limited interoperability of different smart home ecosystems, convoluted set-up procedures, privacy and security concerns, and high costs prevent consumers from easily creating smart home experiences tailored to their wants and needs. For developers, time spent attempting to overcome these obstacles often translates to increased development costs, delayed product launches, and stifled innovation.
Matter, the home automation connectivity standard designed to address these barriers, has been making waves in the smart home industry since its original release in October 2022. The highly anticipate release of Matter 1.2 hit the last year.
What is Matter?
Matter is an application-layer wireless connectivity protocol designed to facilitate the interoperability of smart home devices developed by different brands. The protocol, collaboratively designed by the over 300 industry-leading members of the Connectivity Standards Alliance (CSA), also seeks to enhance privacy and security standards and establish universal, userfriendly device commissioning procedures. Certified devices are rigorously tested to ensure that only high-quality products receive the Matter stamp of approval.
Since its inception, Matter was intended to improve the user experience associated with smart home devices. In stores, consumers would know that devices advertised with the Matter logo would work seamlessly with their preferred
ecosystem, regardless of the developer. At home, installing a new device would be easy, thanks to Matter’s streamlined commissioning system. After installation, controlling new devices would be simple and convenient, thanks to multiadmin features enabled by Matter. In short, Matter was designed to make purchasing, installing, and using smart home devices easier.
However, the integration of Matter also has enormous benefits for product developers. Matter is open source, and Software Development Kits (SDKs) are freely available online. Chip manufacturers like Silicon Labs also have more tailored Development Kits associated with specific hardware platforms available for purchase. Exhaustive testing and certification guidelines are available to product designers, and a fully equipped Matter testing and certification facility has even been opened in Portland, Oregon. The availability of these remarkable tools enables creators of smart home devices to devote less time to the “nuts and bolts” of product development. This allows product developers to do two things: get simple, in-demand products to market faster and at lower costs, allowing them to remain competitive and reach a wider consumer base, and devote more product development time to innovation, resulting in brand differentiation and more opportunities to demonstrate value to customers.
The existence of an industry-wide standard like Matter that encompasses stringent privacy and security standards and requirements for an excellent enduser experience also allows smart home companies to establish their products as reliable and trustworthy. This not only improves the reputation of the IoT as a whole but gives small-to-mid-sized companies the opportunity to compete with long-established industry leaders in the home automation industry, like Apple, Amazon, and Google.
Matter's past
In the past year, Matter has had unprecedented momentum in the smart home industry. Matter 1.0 was released on October 4th, 2022, after only three
years of development, and was deployed at scale within just a quarter of its release. The protocol supported Wi-Fi, Threadcompatible devices, and Bluetooth and included bridging to accommodate other non-IP networks like Z-Wave and Zigbee. The specific smart home devices supported included lights, blinds, thermostats, TVs, access control, safety and security sensors, bridges, and controllers. Matter 1.1 was released on May 18th, 2023; most updates were simple bug fixes, but Intermittent Connected Devices, or “sleepy” devices, were also added to the list of devices included in the protocol.
Matter has been one of the fastestadopted protocols in the history of the IoT. Within a single quarter of the initial release, hundreds of Matter-certified products were already on shelves. And it is not only product developers who are paying attention to Matter; within just one year, millions of certified devices found their way into the homes of consumers, and according to Park Associates (an IoT Market Research company), 37% of consumers already rank Matter certification as being “somewhat critical” or “critical” when deciding whether or not to purchase a smart home product.
Matter’s future
The exciting arrival of Matter 1.2 means support for an extremely in-demand, marketable category of devices: white goods and air quality devices. New device types include laundry washers, refrigerators, robotic vacuum cleaners, air purifiers, smoke alarms, and more. The Matter 1.2 update also adds new features that improve the user experience for commissioning to better describe the product or its elements.
Matter 1.2 signals CSA’s continuing commitment to further improving the user experience, raising the bar for the security and privacy of IoT devices, and streamlining the Matter certification process. This is by no means the end of the line; new updates to Matter are expected to be released approximately every six months, with more device types – from energy management devices to smart refrigerators – added along the way.
Matter 1.2, and all of its past and
future iterations, is actively unlocking potential for innovation in the smart home industry. As CSA continues to expand and the infrastructure surrounding Matter continues to grow, product developers have a unique opportunity to shape the evolution of the industry standard, collaborate with industry peers, and create high-quality smart devices with never-before-seen levels of quality and functionality. As Matter 1.2 opens the door to a new era of innovation, it’s clearer than ever before that the IoT is transforming our lives for the better, starting with our homes.
What are the constituents of Matter?
Matter’s constituents include a modular software stack, plus bridges, controllers, border routers, security, authentication, and cloud connectivity.
By Jeff ShepardNOT elementary particles. The Matter being discussed here is an interoperable application layer software suite for wireless IoT devices. Its constituents include a modular software stack plus bridges, controllers, border routers, security, authentication, and cloud connectivity. Matter uses Thread, Wi-Fi, Ethernet transport, and Bluetooth LE for commissioning.
When the Zigbee Alliance started Matter, it was initially
called Project CHIP. Zigbee changed its name to the Connectivity Standards Alliance and continued refining Matter.
This article begins with a dive into the structure and layers in the Matter software stack, followed by discussions of bridges, controllers, and border routers, and closes with a review of Matter security.
Matter provides a universal open-source abstracted
application layer between the IPV6-based communication protocols in the transport layer and the device application software (Figure 1). The Matter software standard defines the various link layers needed to maintain interoperability.
The Matter software suite architecture comprises six layers below the Application layer: Data Model, Interaction Model, Action Framing, Security, Message Framing and Routing, and IP Framing and Transport management (Figure 2).
The Application layer controls specific device functionality. For example, a thermostat application could include logic for monitoring the temperature and humidity, communicating with remote devices like handsets, and controlling heating and air conditioning systems.
The top layer of the Matter software suite is the Data Model layer, which includes the data and verb elements needed to support the Application. The Application uses those data structures to interact with the lower levels of the device software stack down through to the networking layer.
The Interaction Model layer includes the specific interactions that can take place between a server and client device, like reading or writing attributes on a server device that correspond to application
behavior on the client. The Interaction Model works using the data structures defined in the Data Model.
The Action Framing layer takes the defined interactions and packages them in a binary format suitable for encoding and network transmission.
The Security layer encrypts the framed action message. It adds an authentication code to ensure that the receiver of the message can authenticate the data to maintain the confidentiality and accuracy of the communication.
The Message layer builds and formats the payload with the necessary header fields specifying the message properties and adds the routing information.
The payload is transferred to the transport protocol layer for IP management of the message. When the target device receives the message, the process is reversed, moving up through the layers until it has been formatted for use by the Application layer.
In addition to these layers, the Matter software suite includes specifications for establishing secure communication based on operational certificates or passcodes, setting up group communications and a bulk data transfer protocol for sending bulk data between nodes, and the option for
defining manufacturer- or device-specific protocols. Stacks on individual devices, controllers, bridges, and border routers are also used to construct a Matter network.
Matter controllers
Matter is IP-based and forms local networks using Wi-Fi, Ethernet, and Thread. A Matter controller, sometimes called a hub, enables local Wi-Fi- and Ethernet-based Matter networks to access the Internet supporting remote access to Matter devices.
Existing devices, especially those from Amazon and Google, and some smart home hubs like SmartThings, can receive software updates enabling them to be Matter controllers. Devices with communications abilities independent of Matter, like a Wi-Fi smart thermostat with cloud support from the maker, will still be able to use their native remote-control functions without a Matter controller. Matter is designed to coexist with any manufacturer-provided functionality.
Matter bridges
Matter controllers connect Matter networks with the Internet, while Matter bridges connect Matter networks with other local wireless networks. For example, the Philips Hue Hub can be updated to become
Matter-compatible. When that is done, the Philips Hue smart lighting network can be linked to the local Matter ecosystem.
With a Matter bridge, the individual nodes, like the lights and accessories in a Philips Hue system, will not become directly Matter compatible. Still, they will operate through the bridge and work harmoniously with the Matter network. Bridges are expected to facilitate the adoption of Matter by enabling nearly any other local network to become Matter-compatible, even if the individual nodes are not.
Border routers and Thread
Thread devices and networks are a special case. Thread is a low-power IEEE 802.15.4 IP-based wireless protocol that uses the same frequency Zigbee smart home devices. A border router is designed to communicate directly with Thread devices and connect them with a Matter network. Border routers can link multiple networks and control devices and include an integrated device interface for smart home controls. This is another place that can be confusing: Matter Thread border routers, like Matter controllers, are sometimes called Matter
hubs. When a device is called a Matter hub, it’s important to clarify whether it’s a border router or a controller.
Border routers support integrating very low-power Thread devices like motion, door, and window sensors into a Matter network. Updating a device to become a Matter
Thread border router is more complicated than updating a device to become a Matter controller. That’s because Thread uses IEEE 802.15.4, that’s incompatible with Wi-Fi. Recently, manufacturers have begun making tri-radio devices that support Wi-Fi 6, Bluetooth 5.2, and 802.15.4 and enable the design of border routers and other Matter devices (Figure 3).
Matters of security
Improved network security is a major element of Matter. It encompasses five properties:
Comprehensive — The layered security structure with authentication and attestation for commissioning, protecting every message, and securing over-the-air firmware updates are designed to support comprehensive functional security. Security is independent of the communication
(Image:
protocol that Matter runs on top of. Features like device libraries and application clusters are defined on top of Matter’s core specification. The open-source nature of Matter simplifies security integration and supports interoperability across device types and manufacturers. In addition, Matter uses standard passcode-based session and certificate-based protocols to establish secure sessions for onboarding, attestation, and operation. No device can be added to a Matter network until proven genuine. To guarantee a uniform and compliant ecosystem, Matter also includes the Cloud Security Alliance (CSA) Distributed Compliance Ledger technology in Matter devices to ensure uniform and compliant networks and support worldwide interoperability that enables Matter commissioner devices to check and make sure that devices have been Matter certified.
Strength — Matter employs a variety of techniques to strengthen security. Advanced Encryption Standard (AES) in Cipher Block Chaining-Message Authentication Code (CCM) mode is used for confidentiality and integrity with 128-bit keys. AES in counter (CTR) mode preserves privacy by protecting
identifiers. Secure hash algorithm 256 (SHA256) ensures integrity, and elliptical curve cryptography (ECC) with the ‘secp256r1’ curve is used for digital signatures and key exchanges, standard key derivation schemes, and random number generators.
Ease of use — While it’s both comprehensive and strong, Matter security is designed to be easy to integrate into devices and easy for consumers to use. Test vectors and examples for each aspect of functional security are included in the Matter core specification. Reference implementations are available to Matter designers on the GitHub repository, along with a modular implementation of Matter functional security. Examples are included for alternative integration of hardware security modules (HSMs). Security in Matter devices is designed to be invisible to users; it automatically works without user intervention.
Resilience — Matter security is designed to detect, protect, and recover, and it provides multiple ways to perform some operations. For instance, if a secure session cannot be established using a short
resumption protocol, the full resumption protocol is used. Matter includes a sophisticated message counter algorithm to support resilience to denial-of-service attacks. It has been defined as resilient even when involving sleeping devices or group communications.
Agility — All cryptographic primitives are abstracted in the Matter core specification, leaving the option for revisions that adopt new cryptographic primitives without having to rewrite the basic specification. Flexibility and agility are further enhanced by the modular design of the Matter software suite, enabling some of the modules to be replaced and upgraded to address future developments in security risks and threat analysis.
Summary
Matter is a new interoperable application layer software suite for wireless IoT devices. A Matter network can include bridges, controllers, border routers, and security, including authentication and cloud connectivity. It can also link Amazon AWS, Google, and Microsoft networks into a
Figure 3. Tri-radio ICs are beginning to appear that support Wi-Fi 6, Bluetooth 5.2, and IEEE 802.15.4 for Matter devices. (Image: NXP)
seamless user experience. Only recently have tri-radio ICs been introduced that can support Matter bridges, controllers, and border routers.
References
Connectivity and Matter, NXP Matter Specification, Connectivity Standards Alliance
What is Matter?, Google Home Developer Center
Jetson Orin compatible kit with high flexibility and rapid prototyping
Wide operating temperatures (-40 ~ 85 ºC/-40 ~ 185 ºF)
Wide power input and high vibration tolerance (9 ~ 24VDC; 3.0Grms)
Industrial grade design for easy system integration and mass-deployment
Compatible with Jetson Orin NX and Orin Nano modules
NVIDIA JetPack 5.1 support
Barebones PC with a production carrier board and thermal reference design
Securing devices for the IoT: minimize the attack surface
Meet the growing security challenges of IoT devices and cloud computing by examining common attack vectors and understanding management and protection solutions.By Jeff Shepard
ANattack surface is the sum of all the attack vectors or ways an attacker can gain malicious access to a network or system. The growth in remote work and the adoption of cloud services have increased the number of attack vectors and the attack surface size for most organizations and applications.
This article reviews the different types of attack surfaces, looks at some of the more common attack vectors, and closes with a brief review of how Attack Surface Management (ASM) and Cloud Native Application Protection (CNAPP) can be used to address enterprise security challenges.
Historically, the attack surface has been divided into three segments: the digital attack surface, the physical attack surface, and the social engineering attack surface. More recently, two new attack surfaces have emerged, the artificial intelligence (AI) attack surface and the Internet of Things (IoT) attack surface, and more continue to appear (Figure 1):
• The surface of a digital attack includes all external vulnerabilities accessible through the internet, such as system access points, websites, ports, and services.
• Physical attack surface is all access points into the network hardware, including equipment on-premises, equipment connecting to the network from outside, and malicious employees that share access with unauthorized individuals.
• Social Engineering attack surface includes malicious individuals posing as employees to gain information, capturing credentials through a phishing technique, or sending infected files to an employee.
• AI attack surface takes advantage of inherent weaknesses in AI systems, like their vulnerability to being manipulated by specially engineered data posted to the system. They can also be attacked using a technique called adversarial machine learning that can identify unanticipated security weaknesses in systems.
• IoT attack surface can be surprisingly dangerous. IoT devices are often small, like wireless sensors, but hacking into them can cause false readings to be sent to control equipment, potentially affecting production or damaging large and expensive machinery. Other IoT devices are essential for facility security. The large
numbers and variety of IoT devices can provide an attractive target for gaining access to the broader network.
Types of attack vectors
There can be hundreds of potential attack vectors and large attack surfaces for major operations. Security is a continuous process, especially in large organizations where new software, applications, websites, and hardware constantly appear or evolve. The common types of attack vectors can be obvious or common sense, but they continue to threaten network security, including:
• Compromised credentials, like weak or unprotected passwords
• Phishing attacks or other ways to manipulate employee behavior to grant access to an unauthorized individual
• Malicious and disgruntled employees who intentionally share credentials or sensitive data
• Poor encryption implementations like expired SSL certificates and unpatched data transfer protocols
• Excessive traffic from distributed denial of service (DDoS) attacks
• Misconfigured infrastructure or services
• Unsecured connection with third parties like vendors or customers.
Protection options
ASM and CNAPP are designed to solve different challenges related to enterprise
security. ASM is a broad-based analysis of all available network resources and cyber assets. It considers every aspect of security, from edge devices to the cloud. ASM can be used to define an organization’s attack perimeter and all the vulnerable attack surfaces. ASM aggregates every aspect of the system into a holistic security analysis. CNAPP is a focused dive into all aspects of a public cloud infrastructure. While ASM provides a broad analysis of internal threat surfaces, CNAPP focuses on finding security issues related to cloud infrastructure and associated services like AWS and Microsoft Azure. CNAPP tools check cloud configurations and scan for misconfigurations and vulnerabilities.
Summary
Minimizing attack surfaces is an essential element in IoT and general network security. It involves identifying and minimizing or eliminating the attack surface’s attack vectors. The number and types of attack surfaces and attack vectors are growing, increasing the challenges for security engineers. Tools like ASM and CNAPP are available to help analyze networks and identify potential attack vectors and threat surfaces.
References
8 Immediate Actions to Reduce the Cyber Attack Surface, Cybeready
How do I Reduce My Attack Surface?, Armis
The IoT Attack Surface: Threats and Security
Solutions, Trend Micro
Understanding the differences between Cloud Native Application Protection Platforms and Attack Surface Management, JupiterOne
What Is An Attack Surface?, Fortinet
What is an attack surface?, IBM
What is an Attack Surface? (And the Best Way to Reduce It), StrongDM
What is an attack vector?, CloudFlare
What can designers make with Matter?
Matter provides designers with a unified open-source application layer to speed the development of smart IoT devices.
By Jeff ShepardMATTER
enables designers to develop smart home accessories that work across all major wireless platforms. Mesh functions are possible because Matter operates as an application layer on top of technologies like Ethernet, Wi-Fi, Bluetooth, and Thread. Matter aims to simplify the setup and use of compatible smart home devices and bring some level of interoperability on Google Home, Apple HomeKit, Amazon Alexa, and other platforms.
Matter 1.0 runs on Ethernet, WiFi, and Thread network layers and uses Bluetooth Low Energy for commissioning. It provides designers with a unified opensource application layer to speed the development of smart IoT devices. It’s designed to improve compatibility and ensure interoperability, making it simpler to design devices with smart home and voice services like Apple’s Siri, Google’s Assistant, Amazon’s Alexa, and others. Consumers can add new devices and brands to a Matter smart home network with confidence that they will work together (Figure 1).
The Connectivity Standards Alliance has launched the Matter 1.0 specification as part of a complete development ecosystem, including test cases, detailed testing tools, and a global certification program that includes eight authorized test labs that can test Matter’s underlying network technologies as well as the Matter protocol functions. The Thread Group and Wi-Fi Alliance worked with the Connectivity Standards Alliance to enable the development of the Matter product development and deployment ecosystem. From the start, Matter strongly focuses on security processes and policies, including distributed ledgers and Public Key Infrastructure, to validate devices in real-
time as they are added to the network.
Matter is also designed to enable the optimal wireless protocol for each use case. As noted, Matter initially includes support for Wi-Fi and Thread network layers for core and operational communications and Bluetooth Low Energy (LE) to simplify device commissioning and setup.
Various wireless protocols offer a range of power and bandwidth combinations. Thread, Zigbee, and Z-Wave offer low power operation, Z-Wave and Wi-SUN are suited for longer-range transmissions, and Wi-Fi supports high bandwidths. With Matter, these technologies can share a common application layer enabling seamless communication with the cloud.
Figure 1. Matter supports heterogeneous wireless networks and the integration of multiple voice services. (Image: Silicon Labs)
The Matter specification includes bridging to enable protocols like Zigbee and Z-Wave that are not directly supported to communicate over a Matter network.
Matter simplifies the development process by reducing functionality to a single ecosystem while simultaneously supporting communication and control among several services like Amazon Alexa, Apple Siri, or Google Assistant. Matter provides designers with a common layer for events like commissioning, provisioning, and device and profile discovery over an IP link. All that’s needed is certification of the Matter functionality to ensure interoperability and simplicity of use.
While the Connectivity Standards
Alliance is responsible for both Matter and Zigbee, they are not substitutes, and both will continue to be developed in parallel. There is some relationship since Matter application interactions and objects were inspired by the Zigbee Cluster Library, but Matter is designed to operate on top of IP networking protocols, while Zigbee includes an IP networking protocol. In addition, Zigbee’s default commissioning process uses its IEEE 802.15.4 radio, while provisioning in Matter can take place over Bluetooth LE or Wi-Fi quick response (QR) codes.
Matter provides a universal open-source abstracted application layer between the device application, ecosystems at the top of the software stack, and the IPV6-based communication protocols in the transport layer at the bottom (Figure 2). For full functionality, three types of radios (Wi-Fi, Thread, and Bluetooth LE) and a Matter API are needed to make IoT products from any manufacturer interoperable with other products and ecosystems.
Matter use cases
Matter is initially targeted at smart home networks and has been designed to support low bandwidth, low-energy Zigbee devices, and higher bandwidth networks like WiFi. Matter aims to make those networks interoperable and reliable with a high level of security baked in to make it easier for users to expand smart home networks without having to consider complex factors.
In the future, Matter is expected to be used in a growing range of use cases:
Commercial buildings — Smart commercial building technologies use wireless IoT networks to optimize heating, ventilation, air conditioning, lighting, and overall energy consumption. In addition, access is controlled, and security is maintained wirelessly based on whether the individual is the building owner or landlord versus tenants and guests. Matter will enable the integration of diverse smart building systems into a single network.
Connected healthcare — Personal connected devices operating in Matter enable networks can link individuals at home to doctors’ offices, clinics, and hospitals through robust, secure, and private communications that can adhere to the Health Insurance Portability and Accountability Act (HIPAA) and other international laws related to healthcare data management. The simplification enabled by Matter can help improve the quality of care as well as the quality of life for individuals.
Industry 4.0 — Today, advanced factory automation systems and the industrial IoT (IIoT) use a diversity of networking protocols that can lead to the creation of so-called "automation islands." Matter can link those islands, improving operational efficiencies, lowering costs, and enabling more rapid deployment of emerging automation technologies. Process control, quality, supply chain management, and other business
functions can be improved by leveraging the strengths of Matter-based networking.
Retail & consumer experiences — In retail, there’s a growing need to link in-store and online experiences for customers and management. Improvements in inventory management, knowing what inventory is available at each location in real-time, improved promotional activities, and even improved checkout experiences can all be supported by the diverse networks that Matter makes possible. Security of personal and business information is an important consideration and is supported by Matter.
Connected & autonomous vehicles —
As the automobile industry moves toward autonomous vehicles, connectivity is increasingly important. Wireless connectivity needs in cars and trucks include interactions between vehicles, drivers, and passengers, connecting with smart transport systems, fleet management, vehicle maintenance, and more.
Sustainability & smart energy —
Sustainability is increasingly important and is supported by smart energy and smart cities. Monitoring, measuring, and managing energy generation and consumption is one key to sustainability. The same goes for effective water and wastewater management. Matter combined with wireless protocols like Zigbee Smart Energy can significantly lower the costs when deploying the comprehensive and complex networks needed by these applications. Sustainability solutions need interoperable products, and they need to be adaptable and expandable as needs change and technology advances.
Typical Matter use scenario
Using Matter is not an "either-or" decision. Users can simultaneously install a new Matter device integrated with multiple smart home ecosystems like Amazon Alexa, Apple HomeKit, and Google Home. Device authentication is part of the Bluetooth commissioning process, helping to ensure network security. Users can add devices to Matter networks using a simple step-bystep process. The following example uses
a connected coffee maker, but the device could be an Industry 4.0 node or any other of the use cases outlined above (Figure 3):
• A commissioning device, such as a smartphone or tablet, scans the QR code attached to the back of the coffee maker. The QR code is unique to that coffee maker, identifies the device, and enables secure communication.
• Pressing a pairing button on the coffee maker starts the installation process. The commissioning device uses the cryptographic information included in the QR code link to establish a secured connection to the coffeemaker, verify that it is Matter certified, and identify it as a coffee maker.
• The commissioning device sends the information needed for the coffee maker to join the network, like Wi-Fi passwords and other credentials required to communicate securely with other devices in the network.
• Upon completion of the installation,
the coffee maker can communicate with other devices on the network. For example, a smart speaker/microphone can be used to begin a specific brewing process, set a start time, and alert users when brewing is completed.
Summary
Security and simplicity are two of the hallmarks of Matter installations. Matter includes comprehensive security, including distributed ledgers and Public Key Infrastructure to validate devices as they are added to the network. Adding devices to a Matter network can be a simple process using QR codes and automated commissioning to quickly ensure the reliable operation of diverse platforms like Google Home, Apple HomeKit, and Amazon Alexa. Matter has been designed for use in many use cases, including home, industrial, healthcare, automotive, and smart city networks.
References
A FAQ about the Matter connectivity standard, Texas Instruments Matter, Silicon Labs Matter And Thread Win The IoT Connectivity Wars, Moor Insights, and Strategy
The Matter Standard: Implementing Improved Security and Connectivity for the Smart Home, Infineon
Securing devices for the IoT: firmware, software, and OTA
Open-source standards and industry frameworks are revolutionizing OTA to ensure secure and efficient firmware and software management.
By Jeff ShepardOVERthe air (OTA) updating of firmware and software on Internet of Things (IoT) devices is a requirement, not an option. The large number of IoT devices makes manual updates impractical and even dangerous. This FAQ reviews two key tools for managing and implementing OTA for IoT devices, open-source standards for managing resource constrained devices and industry standards for updating the firmware and software on IoT devices.
Open-source standards for managing constrained IoT devices
The Lightweight M2M (LwM2M) open-source standard from the Open Mobile Alliance SpecWorks (OMA) is built on the success of the Alliance’s OMA device management (OMA DM) standard. LwM2M was designed to reduce power consumption and data requirements to support managing devices with limited processing and storage capabilities (called resource-constrained devices). It supports low-power wireless networking protocols. LwM2M includes datagram transport layer security (DTLS) that’s designed to prevent eavesdropping, tampering, or message forgery. It uses the Constrained Application Protocol (CoAP), a specialized web transfer protocol for use with constrained devices on networks with low bandwidth and low availability (Figure 1).
The CoAP management interface (CoMI) is another option for communications with resource constrained devices. The Internet Engineering Task Force (IETF) Constrained RESTful
Environments (CoRE) working group has standardized CoMI and added functions to make it more suitable for IoT and M2M applications like smart energy and building control networks. It has been optimized to handle installations with large numbers of devices where the messages are infrequent and as small as possible.
Technical Report 069 (TR-069) from the Broadband Forum uses the CPE WAN Management Protocol (CWMP) and defines an application layer protocol for remote management and provisioning of customerpremises equipment (CPE) connected to an Internet Protocol (IP) network. TR-069 supports functions for auto-configuration, software, or firmware image management, plus software module, status and performance management, and diagnostics. CWMP is a bidirectional Simple Object Access Protocol (SOAP)- and HTTP-based protocol. It’s designed for use with a variety of Internet access devices like gateways, modems, routers, and endpoint devices in the IoT.
Update frameworks
Update frameworks are important tools to support secure connectivity. For example, the Software Updates for Internet of Things (SUIT) from the IETF is a firmware updating solution for constrained devices with about 10 kB of RAM and up to 100 kB of FLASH memory. SUIT is currently being defined, and the SUIT working group (WG) has completed two documents:
• An IoT firmware update architecture.
• An information model for the SUIT manifest.
For the next step, the SUIT WG
will be using the Concise Binary Object Representation (CBOR) data format that supports extremely small code size and small messages, and the related CBOR Object Signing and Encryption (COSE) protocol to encode SUIT messages.
The Uptane Alliance has developed its eponymous software update security standard for automotive applications. The Uptain framework assumes that these systems will get compromised and uses multiple layers of security and separation of roles to eliminate single points of failure that might result from any compromise of the system.
For example, Uptain uses two separate data repositories, the image repository, and the director repository, with different signing authorities. Offline keys which are signed by a root signing authority are used to sign images sent to the electronic control units (ECUs) and provide high levels of security. The director repository uses online keys for greater flexibility, and can coordinate software updates with multiple ECUs (Figure 2).
Blockchain technology is another possibility for implementing a secure update framework. CHAINIAC has been proposed as a decentralized software update framework that eliminates single points of failure and supports verifiable integrity and authenticity for software updates. For example, to achieve tamper evidence, consistency, and search efficiency of the timeline, and enable a secure rotation of signing keys, CHAINIAC uses skipchains, authenticated data structures that combine the attributes of skip lists and blockchains.
Summary
Designers responsible for IoT device deployments have numerous choices of open-source standards for managing resource constrained devices like wireless IoT nodes and for managing the delivery of software and firmware updates to those devices.
References
A Secure Software Update Framework for Automobiles, Uptane
CHAINIAC: Proactive Software-Update Transparency via Collectively Signed Skipchains and Verified Builds, International Association for Cryptologic Research
LwM2M — Lightweight M2M standard — protocol and its benefits, AVSystem
Over-the-Air Updates for IoT: What They Are and How to Approach Them, Particle Secure Firmware Updates in the IoT, Competence Centre for ITSecurity at FH Campus Wien
Secure IoT Firmware Updates Are a Necessity for Resilient IoT Deployments, Venafi Securing Automotive Over-the-Air Software Updates, Renesas
Software Updates for Internet of Things (suit), IETF
The Key to Firmware Security in Connected IoT Devices, Keyfactor
Uptane: Securing Software Updates for Automobiles, Uptane
Image: Adobe stock
Securing devices for the IoT: managing memory
Developers must navigate the complexities of managing memory in languages prevalent in IoT development to avoid common security vulnerabilities.
By Jeff ShepardMEMORY management is important in all digital electronic devices including devices designed for use on the Internet of Things (IoT). It prevents memory fragmentation and supports resource allocation and memory utilization, improving overall efficiency. It also supports memory protection and device security.
This article briefly reviews the common weakness enumeration (CWE) scheme for identifying software weaknesses like poor memory management, reviews some of the more common memory security problems, and closes by reviewing how Capability Hardware Enhanced RISC Instructions (CHERI) can be used to address memory management challenges in C and C++ software.
C and C++ are among the most common coding languages used for IoT devices. They are great for creating efficient code but require that developers be wellversed in memory management to properly maintain the stack for storing working variables and the heap for storing longer lived objects and data structures, or risk creating potential security vulnerabilities.
CWE is maintained by MITRE Corp. and is a community-developed list of common software and hardware weakness types that have security implications.
CWE defines a ‘weakness’ as a condition that has the potential to contribute to the introduction of one or more vulnerabilities. The goal of CWE is to provide developers with the insights and information needed to eliminate coding mistakes. An important part of implementing CWE is the scoring system.
Common Weakness Scoring System
The Common Weakness Scoring System (CWSS) is used for prioritizing software weaknesses in a consistent, flexible, open manner. It’s organized into three metric groups: Base Finding, Attack Surface, and Environmental. Each group contains multiple metrics, also called factors, that are used to compute a CWSS score (Figure 1):
• Base Finding metric group identifies the inherent risk of the weakness, confidence in the accuracy of the finding, and strength of controls.
• Attack Surface metric group includes the barriers that an attacker must overcome in order to exploit the weakness.
• Environmental metric group includes the characteristics of the weakness that relate to a specific environment or operational context.
CWE-416, CWE-122, and CWE-401 are three of the most common issues found when manually managing memory in code (along with the associated CWE reference).
Use after free
CWE-416 is the code for if the program attempts to access memory that has been freed; it can cause the program to crash or cause unexpected program behavior. UAF can affect integrity by corrupting valid data, cause program crashes through corrupt data and allow an attacker to launch malicious code.
Heap-based buffer overflow
CWE-122 is a code for if a heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory. Heap-based attacks are more difficult to implement than the stack-based approach but can have more serious consequences. It involves the attack flooding a program’s memory space beyond the memory it uses for current runtime operations. A buffer overflow bug can leave a system vulnerable to attackers who can exploit it by injecting malicious code that can run unauthorized programs or give the attacker administrator access and control of the system (Figure 2).
Missing release of memory after effective lifetime
CWE-401 is the code for Missing Release of Memory after Effective Lifetime is also called missing free (MSF). The program has allocated heap memory but failed to free that piece of memory. If the program doesn’t
free the memory, it can lead to memory leaks. If the process runs long enough, memory leaks can lead to core dumps or low memory conditions making the system vulnerable to denial of service (DoS) attacks.
CHERI
The CHERI architecture extensions were designed by the University of Cambridge and SRI International and extend the CPU instruction set to enable it to access memory using capabilities that access specific areas of memory instead of machine-word pointers. Using capabilities provides finegrained and hardware-enforced access protection. When used with C and C++, CHERI can be used to address memory safety issues without adding the overhead of software runtime checks.
Implementation of CHERI requires minimal changes to existing C and C++ programs. CHERI also enables developers to create separate compartments within a process that can be used for further hardening of the system against attack. Compartments subdivide applications into sections that can interact only in very controlled manners. For example, sensitive subroutines or systems can be separated from the rest of the application, reducing the opportunities for exploitation.
Summary
Security is an important aspect of memory management in IoT devices. The CWE scheme provides a framework for identifying potential memory management problems and quantifying their severity. The CWE website includes an extensive list of common security weaknesses. The CHERI architecture extensions have been developed to speed the implementation of secure C and C++ code.
References
An Introduction to CHERI, University of Cambridge
Automating and Scaling Vex Generation, Open Source Vulnerabilities
Common Weakness Enumeration, MITRE Common Weakness Scoring System, MITRE ISO/IEC TR 20004:2015, Refining software vulnerability analysis under ISO/IEC 15408 and ISO/IEC 18045, ISO
Memory Management Strategies for an Internet of Things System, IEEE International Symposium on Fundamentals of Electrical Engineering
SBOMs and Memory Safety, IoT Security Foundation
Vulnerability Assessment of Sensor Systems, MDPI sensors
How does Matter support multiple fabrics?
There are several best practices and solutions availble to address the technical challenges involved in supporting multiple fabrics within the Matter ecosystem.
By Jeff ShepardINthis context, a "fabric" is a group of networked devices that share the same security domain enabling secure communications within the fabric. Devices in each fabric share the same top-level certificate authority (CA), a Root of Trust determined by the CA, and have a unique (usually 64-bit) identifier called the Fabric ID. To add a node to an existing fabric requires the assignment of unique security credentials to the device, establishing its Fabric ID and enabling it to communicate with other devices on the fabric (Figure 1).
This article reviews how fabrics are administered in a Matter ecosystem, how a Matter device can operate on more than one fabric, and how Matter uses bridges to connect with non-Matter fabrics.
Each node on a Matter network has a node operational certificate (NOC) based on the International Telecommunications Union (ITU) X.509 standard, which defines the format of public key infrastructure (PKI) certificates. X.509 certificates are used to manage identities and security in internet communications and computer networks. Matter uses PKI to facilitate identity.
A Matter node can be part of multiple Matter networks. When that happens, the node has one NOC for each network, also called a Matter fabric. A node's available compute and memory resources determine how many Matter fabrics can be supported at one time. Each fabric has a unique root CA certificate that’s used to validate the identities of the NOCs of the nodes on the fabric. The nodes use the root CA certificate
to validate that a request has been validly issued within a fabric.
Where do the NOC and root CA certificates come from?
Matter nodes join a fabric through the process of commissioning. Commissioning sets the initial configuration for the device using another device called a commissioner, often an app on a smartphone. To add a node, the commissioner sends the NOC and the trusted root CA certificate. To add a node to a second Mater fabric, the administrator tells the device to open its commissioning routine after it has been commissioned the first time. This allows the node to be commissioned to a second Matter fabric.
What are the ten steps of commissioning?
The complete commissioning process is complex and can be broken down into a series of nine stages (Figure 2):
1) Device discovery starts the process with the Commissionee advertising
(Image: Cisco)
itself. The Commissionee can use one of three Commissionable Discovery methods detailed in the Matter specification and must also provide its onboarding information.
2) Connect to the device. After seeing the advertisement, the Commissioner uses the passcode from the onboarding information provided by the Commissionee to establish a passcode authenticated session (PASE) to connect to the device. PASE establishes the security keys that both devices use for communication. The Commissioner also sets up a fail-safe that provides a way to roll back the Commissionee to its original state if commissioning isn’t completed successfully.
3) Get Commissionee information reading all the descriptors. The Commissioner reads all the descriptors from the clusters on the commissionee. Examples include:
• The basic information cluster includes information such as the Vendor ID, Product ID, Product Name, Serial Number, and firmware version.
• The access control list cluster supports the configuration of the access control lists for this node.
• The network commissioning
cluster supports the configuration of a network (Wi-Fi, Ethernet, or Thread) on the node.
4) The Commissioner configures regulatory configuration information, which includes things like configuring the device's location (indoor/outdoor/both) or setting up the country code.
5) Commissionee attestation is used to determine whether a device has been certified and is a genuine Matter device. The commissioner obtains the Device Attestation Certificate (DAC) and the Product Attestation Intermediate (PAI) certificate from the Commissionee. Once the certificates are received, the Commissioner does a challenge request that should be signed by the Attestation Private Key and uses that to establish the authenticity of the Commissionee.
• A certificate Signing Request (CSR) is sent by the Commissioner to the Commissionee. The Commissionee creates a unique operational key pair that will be used in a Certificate Authenticated Session Establishment (CASE) in the final step of commissioning and sends the information to the Commissioner.
6) Node Operational Certificate (NOC) is obtained by the Commissioner using the CSR information. The Commissioner passes the CSR information to the Administrative Domain Manager (ADM) to generate a trusted NOC. The Commissioner installs the Root Certificate on the Commissionee, then installs the NOC.
7) Network provisioning is performed for Thread or Wi-Fi devices when the Commissioner configures the operational network on the Commissionee. Network provisioning is not needed for Ethernet Devices since the device is already connected to the network.
8) Operational discovery occurs when the newly commissioned node is connected to the network. Operational discovery is the process used by Commissioners to find commissioned nodes on the network and know which IP address and port the Commissionee is using.
9) The Commissioner initiates a CASE session with the Commissionee. The Commissionee responds operational
certificates are exchanged, and a shared trust is established by confirming that both devices are in the same logical fabric. At this point, the commissioning process is complete, the Commissioner removes the fail-safe, and the Commissionee can interact normally with all the other nodes on the fabric.
What are Matter bridges and border routers about?
Bridging is about connecting non-Matter devices and fabrics to a Matter fabric. A key benefit of using Matter is that existing devices on Zigbee, Z-Wave, and other wireless networks don’t become obsolete; they can be absorbed into the collective led by Matter. Bridges are important because they enable users to keep existing investments in smart home networks while adding new Matter fabrics over the top. Bridges can be established by upgrading existing devices or with a dedicated bridge device.
If an existing device has sufficient memory and computing resources, it can be upgraded to add bridging functionality. Upgrading existing devices can bring challenges related to latencies and network stability. Suppliers of wireless network ICs are developing bridging devices that combine Matter connectivity with support for already deployed networks like Zigbee and Z-Wave.
Matter and runs over Wi-Fi, Ethernet, and Thread protocols and uses Bluetooth Low Energy (LE) for the commissioning of Thread devices. Thread is an important development related to Matter. It combines the IPv6 internet protocol with IEEE 802.15.4 radio technology and is designed to be secure and future-proof. Thread uses a layer called 6LoWPAN to unify IPv6 and 802.15.4 technologies. A Thread border router is used to connect a Thread network to other Matter fabrics like Wi-Fi or Ethernet. The border router provides services for the Thread fabric devices, like routing services for off-network operation and bidirectional connectivity over IPv6 infrastructure. Bridges and Thread border routers combine to maximize the benefits of Matter and embrace existing wireless fabrics (Figure 3). In addition, on top of a Matter fabric, a Gateway device can provide access to the wider internet and the cloud.
Summary
Security and simplicity are two of the hallmarks of Matter installations. Matter includes comprehensive security, including distributed ledgers and Public Key Infrastructure to validate devices as they are added to the network. Adding devices to a Matter network can be a simple process using QR codes and automated commissioning to quickly ensure the reliable operation of diverse platforms like Google Home, Apple HomeKit, and Amazon Alexa. Matter has been designed for use in many use cases, including home, industrial, healthcare, automotive, and smart city networks.
References
A FAQ about the Matter connectivity standard, Texas Instruments Matter, Silicon Labs
Matter And Thread Win The IoT Connectivity Wars, Moor Insights, and Strategy
The Matter Standard: Implementing Improved Security and Connectivity for the Smart Home, Infineon
When to use standalone or MCU-hosted matter platforms
There’s no simple answer to the question of when to use standalone or MCU-hosted Matter platforms, but there is a lot to consider.
By Jeff ShepardTHEchoice is driven by several factors, including the communications protocol or protocols being used the device type, and location, within the local Matter ecosystem. Solution size requirements, powering expectations, and bandwidth needs are some deciding factors when choosing between various Matter platforms. If an MCU platform is used, there’s the added choice between a real-time operating system (RTOS) or an OS-based environment like Linux.
There’s no simple answer to the question of when to use standalone or MCU-hosted Matter platforms. This article reviews several of the considerations and presents some representative solutions.
While Matter is expected to eventually embrace more wireless communications protocols, today, the choice is limited to Wi-Fi or Thread. Thread fits in applications that need energy-efficient networking and robust connectivity. A Matter device with Thread must also include Bluetooth LE for device onboarding (pairing or commissioning) because smartphones are often used for commissioning and do not include Thread.
Wi-Fi can maximize connectivity performance and is widely available. A Matter device with Wi-Fi does not need to include Bluetooth LE. The choice of communication protocol will directly impact the available development platforms. The type of device is also important when selecting the platform. Matter currently includes six types of nodes or devices (Figure 1):
1) End Nodes, also called Thread sleepy, use only Thread, are usually battery powered, and connect to a Thread edge node or Border Router (orange)
2) Edge Nodes include Thread mesh extenders or Wi-Fi nodes, which are usually AC-powered and connect to End Nodes acting as Thread mesh extenders or to gateways or Thread border routers (green)
3) Thread Border Routers connect the Wi-Fi and Thread networks, are usually AC powered, and can be integrated into other Matter devices (red)
4) Gateways and Hubs connect the Matter network to the cloud and are AC-powered (light blue).
5) Bridges provide a connection between a Matter network and legacy networks and are AC-powered (purple)
6) Controllers are used to provision Matter devices to the system. They can be standalone AC-powered devices but will often be smartphones (medium blue)
Taking the various connectivity possibilities and device types into
consideration impacts the power and performance needs of the application. It helps direct the choice of MCU hosted with an OS like Linux, MCU hosted with an RTOS and standalone Matter implementations. The high-performance requirements of devices like gateways, bridges, hubs, and thread border routers using Thread, Wi-Fi, and/or Ethernet in applications such as smart televisions, security systems, and video door locks can benefit from using a Linux-hosted solution.
Depending on the specific application, edge nodes have the widest range of power and performance needs. As a result, these devices can use OS-hosted –MCU-hosted with RTOS – and standalone Matter implementations. Examples of OS (Linux) hosted edge nodes include smart thermostats and some security systems that use Thread, Wi-Fi, and/or Ethernet. MCU-hosted platforms with RTOS can be used with heating, ventilation, and
air conditioning (HVAC) controls, and smart plugs that use Thread, Wi-Fi, and/or Ethernet; for HVAC controls and smart plugs that use Thread and Wi-Fi, but not Ethernet can often benefit from standalone platforms.
Edge nodes also have a wide range of power and performance requirements depending on the device specifications. These devices rely solely on Thread (with Bluetooth for commissioning). Matter devices like light switches and light bulbs, remote controllers, window coverings, and door locks can be implemented with MCUhosted platforms with RTOS or standalone platforms. Only the simplest Thread devices, like basic sensors and actuators, are best implemented exclusively with standalone platforms (Figure 2).
Linux-hosted Matter
Linux-based MCU-hosted matter devices are currently the most common OS implementation. They can support WiFi and Thread connectivity and can be used to create Thread mesh extenders, Thread border routers, Matter controllers, hubs, bridges and gateways, and Matterconnected media devices and building controls. These tend to be two-board solutions with one board for wireless connectivity and the MCU board for all other aspects of device functionality. These platforms often include hardwareaccelerated video, audio, and graphics
functions to support applications like video streaming and human-machine interfaces (HMIs). The need for speed is well-recognized for video and graphics applications. HMIs are often required to respond accurately in 4 milliseconds to touch screen and gesture inputs. These platforms include extensive security and privacy protection measures; some can be operated using FreeRTOS and Linux. They are often available with application software examples
(Image: NXP)
for Matter devices.
RTOS MCU-hosted Matter
Devices that benefit from using sizeoptimized software for memory-constrained Matter devices can use an RTOS-based design. RTOSs typically do not have the more advanced features in operating systems like Linux, and not all ROTSs are created equal. There are three general classifications of RTOSs:
• Hard real-time RTOSs strictly handle deadlines. That makes them useful in some medical and safetycritical industrial and transportation applications. Hard real-time applications are not a core target of the current Matter specification.
• Firm real-time RTOSs follow deadlines but with more flexibility than challenging real-time implementations. These
RTOSs can be helpful for Matter applications like multimedia systems.
• Soft real-time RTOSs allow some delays in processing. Building automation controls and other non-time critical Matter applications can use these RTOSs.
RTOS size is another consideration. Zephyr from the Linux Foundation is a small open-source soft RTOS; its minimum configuration with threading interrupts and memory allocation is 8K. Adding Bluetooth increases the size to 16K, still small by most standards, making it useful for small IoT devices.
General purpose RTOSs such as FreeRTOS, LynxOS, QNX, and VxWorks are more powerful and can offer firm real-time performance but are also larger.
Zephyr was specifically designed to support resourceconstrained devices across multiple architectures and applications like sensors and actuators on the edge of a Matter network. The Zephyr system architecture separates the OS part, the kernel, and OS Services from the user-specific
application services. The OS part itself contains low-level, platform-specific drivers, Wi-Fi, Thread, and Bluetooth connectivity functions, and the generic implementation of I/O APIs, file systems, kernel-specific functions, and the cryptographic library. The application services layer includes middleware such as message queuing telemetry transport (MQTT), constrained application protocol (CoAP), lightweight machine-to-machine (LwM2M), various libraries, hardware drivers, specific firmware for security, and a secure bootloader (Figure 3). Zephyr is available on several MCU platforms.
There are RTOSs based on the portable operating system interface (POSIX), a family of standards specified by the IEEE Computer Society. Zephyr is not one of them. If a project calls for a POSIX-based RTOS, NuttX may provide an answer. NuttX is a soft RTOS and is scalable from 8-bit to 64-bit MCU environments and is based on POSIX and ANSI standards.
Standalone Matter platforms
For applications like gateways,
hubs, sensors, switches, door locks, lighting, glass break or wake-word detection, and building automation, standalone Matter platforms can speed the development process for low-power smart home devices. These high-performance integrated modules are often based on system-onchip (SoC) devices. They are mostly limited to Matter over Thread with integrated ZigBee and Bluetooth to support simple device commissioning. Some are also available with integrated Wi-Fi.
The basic SoCs include the needed 2.4 GHz RF connectivity, an artificial intelligence/machine learning (AI/ML) accelerator supported by an ARM processor and enough memory for advanced applications. They are designed for low current consumption to support battery-powered designs and include extensive security measures to protect against various cyber-attacks.
In addition to the SoC, some of these integrated modules can include 15 or more discrete components like capacitors, magnetics, and antennas, shrinking the solution and speeding the design
process. The inclusion of a builtin antenna can be especially important. The optimized RF design, including the antenna and needed EMC shielding, has several benefits. It eliminates time-consuming and expensive testing. The resulting device can be RF-certified for worldwide use, including CE (Europe), FCC (United States), ISED (Canada), MIC (Japan), TELEC (Japan), and UKCA (United Kingdom) standards, reducing design risks and further speeding time to market.
Summary
Selecting between standalone and MCU-hosted Matter platforms is not as simple as it might appear. While there are obvious differences in performance between OSbased MCU-hosted platforms and SoC-based modules, there are many grey areas when considering RTOS-based MCU platforms; sometimes, those platforms compete with OS-based designs, and sometimes, they compete with standalone designs. Factors related to wireless connectivity protocols, powering, device type, and application function are all important when weighing the use of the various Matter platforms.
References
A Matter of Interoperability, NXP
Matter: A Unified Approach to IoT Device Development, Silicon Laboratories Matter Development Platforms, NXP
Zephyr Security Overview, Zephyr Projecthealthcare, automotive and smart city
This inaugural event provides a unique platform for manufacturers to engage with industry leaders, technology experts, and peers who are navigating the complexities of digital transformation. Participants will gain invaluable insights into strategies, emerging technologies, and best practices that are reshaping the manufacturing landscape. From implementing Industry 4.0 solutions to leveraging data analytics and smart technologies, the forum delves into strategies that can redefine manufacturing processes and elevate operational excellence.
• Connect with manufacturers, engineers, and industry leaders
• Gain insight on digital transformation trends, technologies, and strategies
• Learn from experts who are now digitally transforming their manufacturing
• Hear and share lessons learned with manufactures across industries
Sponsorship opportunities are available for future Digital Transformation Forum programs. For more information, contact Colleen Sepich. 857.260.1360 | csepich@wtwhmedia.com