An IoT Product Stack Template

Product Architecture 101

 

Getting started with a new hardware project? Think that you have all of the pieces lined up but not sure if it is 100% technically feasible? Want to get a better idea of necessary approximate pricing with relations to COGS and MSRP?

Start with an Architecture Diagram. Architecture diagrams are one of the best ways to get more of the information you need to validate a project’s potential market fit as well as technical feasibility. Arguably, it is the most important hardware startup document, alongside the infamous business plan (ie- the Lean Canvas).

A solidly thought through product architecture document will go a long way with regards to communicating your product’s feasibility: to yourself (most importantly), to potential stakeholders such as your technical team/partner (internal or outsourced), to strategic partners/investors, and even to your customer base.

Architecting the key elements of your technical stack is also often the best way to share your concept and get rough back-of-the-hand numbers on manufacturing costs. Architecture Diagrams are often used as a supplement to a BOM and a standard Product Requirements Document when communicating with service providers and manufacturers.

 

Getting Started with your Architecture Document

There is no “One Ring to Rule Them All” way to build your product’s architecture. One example that I really like was initially designed by some of the smart engineers at the RIot Organization. This template provides a great template for organizing a product’s components into discrete key compartments.

Tom Snyder (CEO of RIoT) often refers to our rapid evolution into the “Data Economy”, where the most important resource is access to the right data at the right time.  Connected hardware products today often serve this purpose of collecting and sending data from our physical environment to some kind of digital software that services a business or convenience function.

It breaks down a hardware product into the basic key elements that need to be accounted for in order to successfully collect and send data. This is a basic template, and it should be noted that often products can grow in complexity to include a variety of factors not incorporated in this template.

RIot Architecture Template Details (re-stated from downloadable PPT above):

EDGE

• Sensor(s) [Hardware]
  • The Sensors box is where you list how original source data is being generated.  This will include sensors that generate structured data (e.g. temperature, humidity, altitude, accelerometer, etc) and sensors that generate unstructured data (e.g. cameras & microphones).  Note that some data is human generated, so don’t forget sources like computer and smart phone interfaces, where people input source data that is utilized in the broader analytics or solution stack.  We don’t often think of humans as “sensors”, but the concept applies in many cases.  For pure software products that do not have a hardware component, you still fill in this box, as you still get source data from somewhere (human, existing database, etc)
• Energy [Power Source]
  • The Energy box on the edge column is how you power your edge devices.  Most frequently, this is with battery or mains power.  Energy harvesting solutions like solar or peltier devices could also apply.  In the case of software only solutions, you may consider where the software runs, and if it is volatile to, for example, a smartphone battery dying.  In some cases for sw only, this box may not apply.
• Edge Compute
  • The Edge Compute box is meant to detail what level of processing is done at that data generation interface.  Is the edge device (or input software) doing any processing at all, or is nothing done until the data is passed to a gateway or cloud layer.  At the edge, you may be doing some filtering, data cleaning, data structuring, etc.  Or you may be doing higher level analytics and only passing pre-processed data to another layer of the communications stack.  List the key processes occurring at the edge, along with any relevant software tools or modules in use.
• Communication [Wireless Protocol]
  • The Communication Box at the Edge layer is where you list by what means you communicate between an edge device and the next communication layer.  This may be to a gateway or router, or directly to a cloud server.  In some cases, everything is done at the edge and there may be no communication at all, but this is rare.  List both wired and wireless connectivity, if both are present.  What radio protocols are used?  For software only solutions, it is often still true that data communication is occurring between the device upon which an application runs, and where data is processed.  This may be over cellular (for example) or via a web-based or cloud communication protocol.
• Actuation [Automated Actions at the Edge]
  • The purpose of IoT systems is to automate processes and workflows.  The actuation box is where you describe the decisions that the system makes, and what follow-on action is then taken.  Does the system physically do something (like adjust a throttle or open a lock) or does it automate an action in a software system (like change a state variable or drive a specific software workflow)?  You do not need to list every possible action, but rather the categories of action that the system drives.

 

GATEWAY

• Local Database
  • The Local Database box is where you list intermediary points of data aggregation for the purpose of processing and/or communication.  This could be caching points in a communication flow or collection points for data cleaning, structuring and fusing.  List here the devices and required capabilities of the gateway (or gateways) in the system.  Note that in some systems there may be multiple layers of gateways.
• Energy [Power Source]
  • The Energy box on the gateway column is how you power your gateway devices.  Most frequently, this is with battery or mains power.  Energy harvesting solutions could also apply.  You may consider redundancy and if your solution is volatile to, for example, a gateway node going offline.  In some cases for sw only, this box may not apply.
• Gateway Compute
  • The Gateway Compute box is meant to detail what level of processing is done at intermediate layers in the communication stack.  You may be doing some filtering, data cleaning, data structuring at this level.  Or you may be doing higher level analytics and only passing pre-processed data to the cloud for final processing or back to the edge to actuate a response.  List the key processes occurring in the gateway, along with any relevant software tools or modules in use.
• Communication
  • The Communication Box in the Gateway column is where you list by what means you communicate between the gateway layer and the cloud.  This may be fiber optic, for example between a cell tower and a data center, or may be with a wireless protocol that is different between edge and gateway versus gateway and cloud.  In some cases, everything is done at the edge and there may be no gateway layer at all.  For software only solutions, this box may not apply – or could be where you consider intermediary credentialing, security or other layers that lie between the application software at the edge and any back end processing that may occur on a different compute architecture.

CLOUD

• Cloud (Compute, Storage)
  • The Cloud box is where you capture all the activity and tools you use in your cloud environment.  Analytics, data storage, aggregation, filtering, and so on.  List all key vendors, code-bases, tools and systems.  You may have ML training data sets along with real application source data.  Keep in mind any redundancies or security tools and layers.
• User Interface
  • The UI box is where you document how your customers and/or end users interact with your solution.  This may include screens, audio, lights, alerts/alarms.  It is where you list any ways that customers can interact and change the solution (access for system updates, software upgrades, setting changes) as well as how they interrogate data to achieve business outcomes.

I have taken the RIoT template and expanded it slightly to include some additional space for the physical encasement elements of products. These can range from simple plastic enclosures to consumer/industrial products with complex electromechanical encasement systems servicing a variety of strict operational and environmental requirements.

• Mechanical (Structure / Housing)
  • The Mechanical box is where you capture the purely mechanical components of the product. This can include necessary encasement features, interface components, sub-assembly products, and even packaging. Although products can range from mechanically complex (ex – robotics with moving parts) to relatively simple (ex – wireless key fob), it is important to think about the mechanical requirements of housing the electronic elements.

You can check out this template and download it here.

I will possibly add a few additions to this post with examples of hardware project architectures.

As always if you have any questions or would like to meet, swing by our daily open hardware meetup between 11:30am-12:30pm PST at our Hardware Summit digital meeting space and say hi!