Diagnosing Distroless .NET Applications on Kubernetes

Minimal container images are a good production default. Distroless and chiseled .NET images reduce image size and attack surface by leaving out package managers, shells, and troubleshooting tools.

That becomes a challenge when a running application has high CPU usage, increasing memory consumption, or unexplained latency. Installing tools in the application container is not an option, and rebuilding the image changes the environment that needs to be investigated.

Validate OPC UA Address Spaces Before Integration

An OPC UA server can be reachable, browsable, and able to return values while its address space is still modeled incorrectly. A mandatory component may be missing, a Variable may use the wrong DataType, or a node may appear at the wrong place in the hierarchy. These problems are easy to overlook in a client browser, but they often surface later when another application relies on the information model instead of only reading individual NodeIds.

Crow’s NestMQTT and the Vibe Engineering Adventure

In the world of (Industrial) Internet of Things (IIoT), MQTT is a widely adopted messaging protocol. Whether you’re debugging a flaky device or trying to understand system-wide message flow, a good MQTT client is a lifesaver.

There are many excellent MQTT clients available—like MqttExplorer, MQTTX, mqttui, and the classic mosquitto_sub. However, none quite met my specific needs. That kicked off a wild journey: building my own client, Crow’s NestMQTT, while exploring how Generative AI can accelerate software development.

Harnessing the Power of Small Language Models in Industrial IoT

The industrial Internet of Things (IIoT) is revolutionizing how industries operate, bringing connectivity and data-driven insights to every corner of the manufacturing process. As IIoT devices proliferate, the need for robust, efficient, and intelligent data processing becomes increasingly critical. This is where small language models come into play, particularly in the context of intelligent edge scenarios where offline capabilities are paramount.

Introduction

The Industrial Internet of Things (IIoT) is at the forefront of a significant transformation in the manufacturing sector, driven by the convergence of advanced technologies, hybrid intelligent edge solutions, and AI. This evolution is not merely about adopting new technologies but about redefining how manufacturing processes communicate, interact, and operate in a connected world. This blog post explores these pivotal advancements, highlighting their role in streamlining operations and fostering a more agile, efficient, and interconnected manufacturing environment.

In this comprehensive tutorial, we will explore the process of OPC UA data modelling. The tutorial will cover modeling a machine, creating an OPC UA server to simulate machinery values, reading data from the server and transmitting it downstream (e.g., to the cloud), and detecting anomalies.

What is OPC UA?

To answer this question, I like to cite Stefan Hoppe the President and Executive Director of the OPC Foundation:

OPC Unified Architecture (OPC UA) is the information exchange standard for secure, reliable, manufacturer- and platform-independent industrial communications. It enables data exchange between products from different manufacturers and across operating systems. The OPC UA standard is based on specifications that were developed in close cooperation between manufacturers, users, research institutes and consortia, in order to enable consistent information exchange in heterogeneous systems.

For nearly three decades, OPC has been, and continues to be, the go to connectivity standard in indus- try. With the advent of the Internet of Things (IoT) era, OPC adoption has also shown growth in new, non-industrial markets. By introducing a Service-Oriented-Architecture (SOA) in industrial automation systems in 2007, OPC UA started to offer a scalable, platform-independent solution for interoperability which combines the benefits of web services and integrated security with a consistent data model.

Today I Learned that the default stack size for threads in dotnet e.g. the ThreadPool threads is OS dependent. On Windows it is 1.5 MiB, on Linux, MacOs it is dependent on the concrete OS version. To determine the actual default thread size you have to run ulimit -s. For Ubuntu 22.04 it is 8192 bytes and for macOS 14.2 it is 8176 bytes.

It is possible to configure the default stack size via environment variable e.g. to set the stack to 1.5Mib set DOTNET_DefaultStackSize=180000 (the value is interpreted as hex).