Core Technologies and Best Practices for Building Enterprise IoT Software Platforms
The software platform knowledge base focuses on the design and implementation of IoT software systems, covering core technology areas such as cloud platform architecture, microservice design, API interfaces, device management, data processing, and edge computing. Click on a term to see a detailed explanation.
This section collects software terms cut by responsibility, so a component's role in the system can be checked against them. Basic technologies discuss which logical blocks a platform is made of, such as access, interfaces, device master data, data storage, and message passing. Platform architecture and microservices discuss how those blocks are deployed on their own and how they call each other. The distributed group discusses how queues, storage, cache, databases, and scheduled triggers hand the right to execute from one node to another. The data-processing group discusses the path point data takes from cleaning through computation to display. The edge group discusses which capabilities remain on site when rules, local persistence, model inference, and protocol conversion stay in the field. Industry systems discuss which on-site layer the software boundary lands on when those capabilities are assembled into a home, agriculture, vehicle, or city application. Open-source projects state which of the responsibilities above a specific broker or platform implements.
The same everyday word points at a different grain in different directories. For storage, first separate Distributed Storage used for objects and files from a local cache on an edge gateway that disappears when the device loses power. For messages, separate the queue that hands a payload from a device to a service from continuous computation over events already in the queue. The directory is that responsibility label. It tells the reader which role the next page discusses. It does not promise that any single page covers a whole IoT platform.
These entries are useful once the question can already be placed on the device side, the edge side, or the cloud side, and once you can say whether the data in front of you is a command, a state, a file, or a time series. When the only sentence left is "the platform is unstable," the directory cannot choose a page, because instability may come from access authentication, a message backlog, overlapping tasks, or query definitions that do not match. Add one sentence about who saw what phenomenon on which interface, then open the matching entry. If the firmware did not change to the target version, go to the upgrade system under device management. If the curve does not match the field, go to data processing, and stop rechecking the upgrade task.
Entries can be read in a series, but the order matters. Use IoT Platform Architecture first to build the block diagram, then read the specific components, and read industry systems last to see which components a scenario actually uses and which are limited by power and the network. An open-source project page fits after you already know you need a lightweight broker, or a platform with a rule chain, and you want to compare that need with a real implementation. Using it as the first step of selection turns that project's default topology into an architecture constraint.
While looking something up, it is easy to write a vendor product name, a communication protocol name, and an architecture role as one word. A protocol decides how a payload is encoded, a broker decides how a connection is kept, and a platform decides how devices, rules, and screens are organized. All three can appear in one project. When locating a fault, pin one layer first. Recording "cannot reach the cloud" as a protocol problem, a broker problem, and a platform problem at the same time makes the investigation jump among the three layers, with only a surface check on each.
Using an industry-system page in place of a component page is another kind of drift. An industry page describes the closed loop the scenario software must finish, such as an irrigation action or the status of a municipal facility. It does not say how a queue is sharded or how object expiry is set. Reading only component pages misses field constraints: whether the edge has stable power, whether the device stays online for long periods, and whether a downlink command can actually arrive the next time the device wakes. Skip those constraints and a cloud feature list is treated as a condition the site already has. Default settings of open-source projects often favor a demonstration. Putting a demonstration topology straight onto multi-tenant production treats a single-machine process as a cluster that already fails over.
The directory page does not store interface fields. When an abbreviation appears, first confirm whether this section means an architecture role, a component that is running, or a project that can be installed. Scheduling decides who receives the right to trigger. A queue decides how a payload is buffered in transit. Both relate to asynchronous work, and the faults differ: overlapping schedules write a report twice, and a queue backlog slows the real-time path. Applying one entry's conclusion to the other adds machines on the wrong layer. Field constraints on an industry-system page also cannot be copied straight in as a component's default parameters. A component page gives the mechanism. Specific parameters wait until power, latency, and data volume are known.