Building IIoT That Lasts: Lessons from the Field

Summary

The article provides ten lessons for building long-lasting Industrial IoT (IIoT) systems, emphasizing firmware development ownership, device longevity, and data integrity. It advises using standard protocols, buffering data, and phased firmware releases to ensure reliability and efficiency. The authors draw from their experience to offer practical guidance.

Key Takeaways

1. Own firmware development to quickly fix issues and maintain security, avoiding reliance on external vendors.
2. Design hardware with extra processing headroom and replaceable components to extend device longevity and accommodate future features.
3. Implement local data buffering and edge processing to ensure data integrity and reduce bandwidth usage during network outages.

Statement Breakdown

• Claimed Facts: 60% of statements the article presents as facts
• Opinions: 30% of statements classified as editorial or subjective
• Claims: 10% of statements surfaced for additional reader evaluation

Credibility & Bias Reasoning

Credibility assessment: The article provides practical advice based on the authors' experience in deploying Industrial IoT solutions. It offers specific examples and technical details, enhancing its credibility. The advice is actionable and grounded in real-world challenges, increasing confidence in the information presented.

Bias assessment: Pragmatic Solution-Oriented. The article focuses on practical solutions and best practices for building durable IIoT systems. It emphasizes maintainability, security, and longevity, reflecting a solution-oriented perspective. The content is geared towards helping readers avoid common pitfalls in IIoT deployments.

Note: This article offers experience-based advice on IIoT development. Consider the specific context of your projects when applying these recommendations.

Credibility flag: Practical Guidance

Claimed Facts (7)

• This is presented as a factual observation about the current state of IoT deployments.
• This describes the typical architecture of modern IoT development.
• This states a common practice in IoT messaging protocols and services.
• This is a statement of fact about the reliability of cellular networks.
• This describes a common issue with sensor data integrity.
• This is a factual statement about the efficiency of data transmission.
• This is a factual statement about the potential consequences of faulty firmware updates.

Opinions (7)

• This is a subjective recommendation on what aspects of IoT development should be kept internal.
• This is an opinion on the value of investing in hardware with extra capacity.
• This is a subjective assessment of the value of IP ratings.
• This is an opinion on the drawbacks of using custom protocols.
• This is a suggested solution based on the author's perspective.
• This is a subjective assessment of the value of long-term data storage.
• This is an opinion on the value of batching data.

Claims (7)

• While generally true, this statement lacks specific evidence and can be seen as an oversimplification.
• This is a generalization that may not always be true, as lab tests can catch different types of issues.
• This is vague and lacks specific guidance on how to determine the necessary granularity.
• While desirable, this is not always a strict requirement and depends on the specific hardware and update strategy.
• This is an exaggeration, as the impact of delay depends on the specific context and severity of the issue.
• While there are potential risks, this statement is broad and doesn't acknowledge the possibility of secure vendor relationships.
• This is a generalization that may not always be practical or necessary, depending on the specific deployment environment.

Key Sources

• Alex Sergeyev — Author
• Mooracle AB — Author