Arm MDK-Middleware and CMSIS for Indian Industrial…

An Indian industrial IoT product, a building management controller in Mumbai, an energy meter uplink in Delhi NCR, a factory gateway in Pune, or a panel HMI controller in Chennai, usually ships with the same software shape: a Cortex-M MCU, a TCP/IP stack talking TLS to a cloud endpoint, a file system on an SD card or internal flash, sometimes a USB console or a USB mass-storage drop, a signal-processing pipeline on the inputs, and an RTOS holding it all together. Every one of those layers is available inside a single commercial licence from Arm Keil MDK, purchased through Arm’s authorized partner in India for Arm Development Tools, GSAS Micro Systems. This post is a deep tour of the MDK-Middleware bundle and the CMSIS software layer that Indian industrial IoT teams consume as part of their MDK Essential or MDK Professional subscription, what the pieces are, how they fit together, and why a single-vendor stack is worth paying for.

MDK-Middleware: the bundled integration layer

MDK-Middleware is the set of pre-integrated middleware components that Arm bundles into every MDK v6 edition, Community, Essential, and Professional: per Arm’s published editions matrix on keil.arm.com. It is not a loose collection of libraries, it is a coherent stack designed so that the file system, the networking stack, and the USB stack all share the same CMSIS-Driver abstractions, the same CMSIS-RTOS2 threading model, and the same debug and trace integration in µVision and Keil Studio. (Indian commercial product teams pick MDK Essential or MDK Professional rather than Community, because Community is non-commercial use only, but the MDK-Middleware deliverable is identical across the three.)

File System

The MDK-Middleware File System component is a FAT file system with production-grade driver support for SD and SDHC cards over SD/MMC or SPI, USB mass storage (both host-side and device-side), internal flash, and RAM disk. It supports long file names, multiple volumes, concurrent file handles, and wear-levelling-friendly usage patterns on flash. For an Indian factory gateway that buffers sensor batches to local storage when the cellular uplink is down, the file system drops in without the team writing a FAT layer themselves or integrating an outside library. For a building management controller in Mumbai that logs alarm events to an SD card for service technicians to retrieve, the same component covers the requirement, and the debug view of open files and free space is available directly inside µVision.

Network

The MDK-Middleware Network component is the heart of most Indian industrial IoT products. It is a full dual-stack IPv4 and IPv6 TCP/IP implementation with HTTP and HTTPS server and client, DHCP, DNS, SMTP, SNMP, Telnet, FTP, and a BSD-style socket API for teams that want to write their own protocols on top. TLS is provided by integrated mbedTLS, which means an Indian energy meter sending telemetry to a cloud endpoint does not need a third-party TLS library or a bespoke crypto integration, the commercial MDK Essential or MDK Professional licence covers it.

The practical implications for Indian industrial IoT are significant. A factory gateway team in Pune can host a local configuration web UI on the embedded HTTPS server, proxy commands from the cloud through an authenticated HTTP client, and expose an SNMP agent for a plant-wide network management system, all from one stack, with one set of build flags, under one support contract. A device in the field that needs to send an email alert on a fault condition uses the SMTP client; a service technician connecting over the local network uses Telnet or FTP for maintenance access; DHCP and DNS clients mean the device fits straight into the plant’s IP fabric without static configuration.

USB

The MDK-Middleware USB component includes both host and device stacks. On the device side, Indian industrial products commonly use HID for keypad/front-panel emulation, CDC for a virtual COM port configuration console, mass storage to expose a configuration file area to a service technician, and audio or printer class as needed. On the host side, a Cortex-M controller can enumerate USB flash drives for firmware updates or data logging, a frequent request for Indian HMI and controller products where on-site technicians prefer a USB stick to a network drop.

Because the USB stack is built against CMSIS-Driver, the same code runs across STMicroelectronics STM32 F4/F7/H7/U5/H5, NXP LPC/Kinetis/i.MX RT crossover parts, Renesas RA/Synergy, Nordic nRF52/53, Infineon PSoC 6/XMC, Silicon Labs EFM32, TI TM4C/SimpleLink, and Microchip SAM silicon. A team porting a product from one MCU family to another keeps their USB code intact; only the driver layer changes.

A note on graphics

Historically MDK-Middleware also included a graphics component. Today, most Indian teams building rich HMI screens on Cortex-M7 and Cortex-M55 parts source their graphics library separately, typically SEGGER emWin or another third-party library, and integrate it into their MDK project as a separate pack. That is an ecosystem choice rather than a licensing constraint: the MDK project still builds with Arm Compiler 6, still uses the CMSIS-RTOS2 RTX5 kernel, and still debugs in µVision or Keil Studio. Indian HMI teams looking at a new controller should budget for a separate graphics licence rather than assume MDK-Middleware covers it.

CMSIS: the cross-vendor software layer underneath

Where MDK-Middleware is the integration bundle, CMSIS is the vendor-neutral software standard that sits underneath every MDK project, and underneath a lot of non-MDK projects too. An Indian industrial IoT team using MDK Essential or MDK Professional gets the full CMSIS stack inside their commercial licence.

CMSIS-Core

CMSIS-Core is the Cortex-M hardware abstraction layer, the startup files, core register access, SysTick, NVIC configuration, and system-level APIs that every Cortex-M program needs. It is the layer every silicon vendor implements for their parts, which is why adding support for a new STM32, NXP, or Renesas device in an MDK project is a pack install rather than a porting exercise.

CMSIS-DSP

CMSIS-DSP is Arm’s production-grade signal processing library for Cortex-M. It provides FIR/IIR filters, FFTs (real and complex), matrix operations, statistics, interpolation, and transforms, with hand-tuned implementations that use the Cortex-M4 and Cortex-M7 DSP extensions, and Helium (M-Profile Vector Extension) on Cortex-M55 and Cortex-M85. For an Indian energy meter running a Goertzel algorithm or a harmonic analyser on the mains waveform, CMSIS-DSP is the difference between writing the filter maths from scratch and calling a vetted library. For an Indian industrial predictive-maintenance sensor running a vibration FFT on a Cortex-M7, the same applies.

CMSIS-NN

CMSIS-NN provides quantised neural network kernels optimised for Cortex-M. Convolution, depthwise convolution, pooling, fully connected layers, and activation functions are all implemented for 8-bit and 16-bit quantised inference. For Indian teams running a small TinyML model on a Cortex-M, an anomaly-detection model on a factory sensor, a wake-word on a field device, a compact classification model on an HMI, CMSIS-NN is the runtime layer underneath. On devices that pair Cortex-M with an Arm Ethos-U microNPU, CMSIS-NN is also the layer that hands off to the NPU, giving teams a path to accelerate inference without rewriting the model.

CMSIS-Driver

CMSIS-Driver defines vendor-neutral peripheral driver APIs, I2C, SPI, USART, Ethernet MAC, USB, SAI, CAN. Silicon vendors implement these drivers for their parts, and middleware components (MDK-Middleware File System, Network, USB) consume them through the standard interface. The result is that an Indian factory gateway designed on an NXP part can port to a Renesas part with driver-level changes and not stack-level changes, a real cost saving when a supply-chain disruption forces a last-minute silicon swap.

CMSIS-RTOS2 and RTX5

CMSIS-RTOS2 is the RTOS abstraction layer, and RTX5 is Arm’s reference implementation shipped with MDK. FreeRTOS is also available as a CMSIS-RTOS2 implementation for teams that prefer it. The value of the abstraction is portability: middleware written against CMSIS-RTOS2 runs on RTX5 and on CMSIS-FreeRTOS without modification. For an Indian team standardising on RTX5 for its Event Recorder integration, and another Indian team in the same company standardising on FreeRTOS for a different product, sharing middleware across both is straightforward because both kernels present the CMSIS-RTOS2 surface.

CMSIS-Pack

CMSIS-Pack is the packaging format that ties everything together. Silicon vendors publish packs (device headers, startup files, flash algorithms, SVD peripheral descriptions). Middleware vendors publish packs. Board vendors publish packs. An MDK project is a manifest of the packs it consumes, and the pack manager in µVision or Keil Studio resolves the dependency graph. For Indian teams running multi-product programmes, the pack model is the reason a shared component library can live in one place and be consumed by every product.

Why Indian industrial IoT teams commit to this stack

The commercial argument is rarely about any one component. It is about the whole shape of the stack.

First, one licence path. MDK Essential or MDK Professional covers the compiler, the IDE(s), the middleware, the RTOS, and the CMSIS software layer in a single commercial subscription, with a single support contact at GSAS, Arm’s authorized partner in India for Arm Development Tools. Indian procurement teams managing a multi-vendor BoM appreciate the arithmetic.

Second, silicon portability. Because CMSIS-Driver sits under the middleware, porting an Indian industrial product from one MCU family to another does not ripple up through the application code. Supply-chain-driven silicon swaps, which have been a fact of life for Indian OEMs, are driver-level ports, not rewrites.

Third, vendor-accountable debug. The Event Recorder and Execution Profiler views inside µVision and Keil Studio render RTX5 thread timelines, MDK-Middleware object state, and CMSIS-Driver transactions using the same UI. When an Indian team is chasing an intermittent TLS handshake failure on a live device in a factory, being able to capture a trace and review it in a vendor-supported tool is a real engineering lever.

Fourth, tool qualification at the MDK-Professional tier. Indian industrial OEMs working toward IEC 61508 functional safety certification can pair MDK-Professional with Arm’s FuSa compiler and runtime packages, documenting a single audited toolchain rather than a patchwork.

Target use cases across Indian industrial IoT

The stack maps cleanly to the Indian industrial IoT shapes we see most often. An Indian HMI controller uses CMSIS-Driver for the touch and display bus, MDK-Middleware USB for a configuration drive, MDK-Middleware File System for the asset library, RTX5 for threading, and a third-party graphics library for the UI. An Indian building management system controller uses the Network component for SNMP, HTTP, and DHCP; the File System for logs; and the USB device stack for service access. An Indian energy meter uplink uses CMSIS-DSP for waveform analytics, the Network component for TLS-protected telemetry, and RTX5 for deterministic scheduling. An Indian factory gateway appliance uses the full Network component (DHCP, DNS, HTTPS client for cloud, SNMP for local NMS), the File System for buffering, and CMSIS-NN for a local anomaly model, all under one MDK Essential or MDK Professional licence.