Usman Mehmood

The Simplifier Gateway is an industrial functional-safety communication device developed as part of the Safety Simplifier ecosystem. It connects decentralized safety devices and safety I/O systems to higher-level industrial safety networks, enabling machine-safety data to be collected, processed, and forwarded to safety controllers. The device is certified up to SIL 3, making it suitable for demanding machine-safety applications that require a high level of diagnostic coverage, deterministic behavior, and compliance with functional safety standards such as IEC 61508.

The Gateway architecture contains two dedicated safety cores and one separate communication core. The safety cores are responsible for safety-related processing, diagnostics, monitoring, and validation of safety communication, while the communication core handles network-facing and non-safety communication tasks. This architectural separation supports clear responsibility boundaries between safety and communication functions. In addition to the existing PROFIsafe variant, an FSoE variant has also been developed and is currently submitted for SIL 3 certification.

My role in the project covered embedded firmware development, safety verification, automated testing, embedded DevOps, and certification evidence generation. I worked on bare-metal driver development, implementing low-level firmware components close to the hardware and ensuring that the software behavior met the deterministic and reliability requirements expected from a safety-certified embedded device.

A major part of my work was the development and maintenance of unit tests for the complete in-scope firmware of the safety cores. I achieved 100% statement and branch coverage for all in-scope safety firmware using a combination of HIL testing and fault insertion, excluding certified third-party components and toolchain libraries. To support this, I developed a custom unit testing framework tailored specifically to the Gateway's firmware architecture and safety-core constraints. This framework enabled systematic, repeatable, and traceable verification of safety firmware behavior and became an important part of the project's quality and certification workflow.

I was also involved in code reviews and architectural reviews, focusing on safety, maintainability, traceability, and compliance. I contributed to the project's software quality activities through MISRA analysis and enforcement, code complexity analysis, and the review of safety-relevant implementation decisions. These activities were not only internal quality measures, but also part of the formal evidence required for certification.

In addition, I created and maintained official documentation for the certification evidence package, including documents related to code reviews, unit testing, test coverage, MISRA compliance, MISRA deviations, and code quality analysis. These documents formed part of the official document release required by the certifying body when assessing the product for SIL 3 compliance.

I also solely developed and maintain the embedded DevOps infrastructure. This included building and maintaining CI pipelines for regular firmware builds, automatically executing unit tests and HIL tests on each build, and generating proof-of-review documentation from GitHub pull requests and review comments. This improved process traceability and helped ensure that review evidence could be collected and presented consistently during certification activities.

Beyond implementation and testing, I actively participated in functional safety and compliance meetings, helping to design, review, and verify the device architecture against IEC 61508 requirements. I also developed firmware upgrade utilities for field firmware updates over CAN bus, enabling controlled DFU procedures for deployed devices.

Overall, my work on the Simplifier Gateway combined low-level embedded development, safety-critical firmware verification, automated testing, compliance documentation, and certification support for a SIL 3 industrial safety device.

To take SSP's Simplifier Gateway from certification into stable serial production, I designed the end-of-electronics production test that screens every unit before final assembly. The test focuses on catching hardware and communication faults immediately after the six-PCB assembly is formed, before it is fitted into its mechanical enclosures.

The test system loads the target firmware onto each device, and exercises core interfaces (digital I/O, UART, CAN, analog voltages, resistances, and Ethernet reachability), so units leave the station production-ready. It also writes pass/fail, as well as many other stats to our ERP system for good traceability.

The solution is a Beckhoff TwinCAT 3 test cabinet built around a CX7080 with RS-232/RS-485, plus EtherCAT terminals selected to cover the device's I/O profile: EL2008 for digital outputs, EL3174 for voltage measurement, EL3692 for resistance measurement, EL6751 to transmit/receive CAN frames (multiplexed via relays across the gateway's two CAN ports), and EL6631 to exercise PROFINET/PROFIsafe paths; the rig also controls a digital power supply over RS232. A .NET (C#) application orchestrates the entire test sequence, talking to the PLC via Beckhoff ADS and to the DUT/ERP directly; the steps are defined in JSON so they can be reordered, skipped, or duplicated without code changes.

Developed embedded firmware and supported electronics redesign for a pair of BLE-connected smart shoe insoles based on Nordic nRF52840. Each insole used 8 force sensing resistors and an ICM-42670 IMU to measure plantar pressure and movement.

The firmware sampled sensors at 200 Hz, decimated data to 100 Hz, performed sensor fusion and step-event detection, coordinated a primary/secondary BLE topology, stored sessions in low-power flash when the app was unavailable, and synchronized data later when the app reconnected.

The firmware ran on Zephyr through Nordic's nRF Connect SDK and used a hardware-watchdog-enforced, event-driven architecture with lean ISRs and work-queue-based deferred processing. It also used application-level BLE peer authentication, dynamic role resolution, MTU-aware transport behavior, and MCUboot plus mcumgr over BLE for OTA updates.

A Visual Studio Code extension designed to simplify the development workflow for C and C++ projects that use CMake. It provides an integrated environment for creating, building, running, debugging, and testing projects directly from within VS Code. Instead of requiring users to manually create project folders, CMake files, build configurations, and debug settings, the extension automates much of this setup and presents the most common actions through convenient commands and status bar buttons. The extension has grown into a serious developer tool and has reached over 20,000 downloads.

The extension is implemented as a JavaScript-based VS Code extension. Its configuration defines command palette commands, activation behavior for C and C++ projects, code snippets, and integration with supporting tools such as CMake, GCC, GDB, Ninja, Make, Git, and testing or coverage utilities. The extension registers multiple developer actions, including project creation, build type selection, clean builds, running executables, starting debug sessions, running tests, and debugging tests.

A major feature of the extension is project generation. It can create new C or C++ projects with a ready-to-use structure, including source files, CMake configuration, and VS Code settings. It also supports creating libraries and adding reusable components to an existing project. These components can include implementation files, headers, mock files, and test files, while the extension updates the CMake configuration so the new code becomes part of the build system automatically.

The build workflow is based around CMake. The extension manages build folders, selected build modes, compiler paths, generated executables, and debugger configuration. It supports common build types such as Debug, Release, and Test, allowing users to move between normal development, optimized builds, and test-focused workflows. The testing support is especially useful for structured C/C++ development, where automated tests and coverage tools are often part of the workflow.

Another important part of the extension is tool detection and installation support. It can check whether required development tools are available and help install missing tools using platform-specific package managers, reducing setup friction for new environments.

Overall, C C++ Toolkit is a practical VS Code extension for C and C++ developers who want a smoother CMake-based workflow. It is useful for beginners setting up projects quickly, as well as experienced developers who want faster project creation, easier build management, integrated debugging, and streamlined testing inside VS Code.

EzLogger is a lightweight asynchronous logging framework for .NET applications, designed to provide dependable runtime logging with minimal setup and low execution overhead. It offers a simple, accessible API for writing log messages at six severity levels: Critical, Error, Warning, Announce, Info, and Debug, while keeping logging work separate from the main application flow. Rather than aiming for the extensive configurability of larger logging ecosystems, EzLogger focuses on practical usability, predictable behavior, and efficient operation for applications that need straightforward logging without unnecessary complexity.

At its core, EzLogger follows a queue-based architecture. When the application emits a log message, the message is timestamped, converted into an internal log record, and placed into a thread-safe logging pipeline. Multiline messages are split into individual log lines while preserving their original timestamp, ensuring that output remains clear and structured. Because log generation is decoupled from log writing, the calling thread can continue its normal work immediately instead of being blocked by console or file I/O.

The framework processes logs through a dedicated background logger service. This service waits for incoming entries, gathers all currently available messages into a batch, and then dispatches that batch to the configured output targets. Console and file logging are handled independently, allowing each destination to use its own verbosity threshold. This makes it possible, for example, to keep console output concise while still writing more detailed diagnostic information to file. Batch processing further reduces overhead by avoiding unnecessary per-message write operations and improving throughput during periods of heavier log activity.

For persistence, EzLogger writes logs to date-based files inside an application-specific log directory. Console output is formatted for readability, while file output is coordinated to ensure safe and consistent writes. In addition to logging itself, the framework includes a separate background cleaner service responsible for automated log retention. This service periodically checks the total size of the log folder and, when the configured limit is exceeded, removes the oldest files until storage usage falls back within bounds. This makes EzLogger suitable for long-running applications where unattended log growth must be controlled.

The overall architecture is intentionally compact and service-oriented: the main application produces logs, the logger service processes and writes them asynchronously, and the cleaner service manages storage in the background. During application shutdown, EzLogger completes pending work and flushes queued messages before exiting, helping ensure that important log data is not lost. In this way, EzLogger provides a balanced combination of simplicity, efficiency, and reliability.