Safety-critical industrial software has a quality bar that most software development organizations have not encountered. When the product configures gas detection systems that protect human life, testing is not a delivery phase. It is a design requirement.
The TPPR engagement with Honeywell brought Parallel Minds into a co-delivery model with a safety instrumentation leader to accelerate both product feature delivery and test automation quality.
Quick answer first
The Honeywell TPPR configurator is a C#/WPF configuration application with rule-based system validation, SAP-ready order handoff, and a bespoke test automation framework achieving 98%+ code coverage across 10,000+ unit tests on Windows CE.
The product challenge
Sales engineers configuring TPPR gas detection systems were working from spreadsheet-based templates without a connected validation engine. The path from customer requirements to an approved configuration was manual, error-prone, and time-consuming.
A configuration error in a safety-critical system is not a UX problem. It can mean incorrect system sizing, wrong device selection, or a safety gap that reaches the field before it is caught.
The product needed to make correct configuration the default behavior, not the outcome of careful manual review.
What the configurator delivers
Guided configuration
Users work through project type and gas detection architecture selection in a structured sequence. The UI presents only the options that are valid for each configuration state, preventing invalid combinations before they can be submitted.
Intelligent validation
The validation engine applies rule-driven checks for completeness, correctness, and safety compliance. This includes power budget validation - ensuring the configured system is within the power supply envelope - and thermal analysis within configuration flows.
Config-to-order handoff
Approved configurations generate manufacturing-ready artifacts: technical build sheets and BOM reports that feed production processes downstream. The handoff eliminates the manual translation from configuration decisions to manufacturing instructions that previously created errors.
The quality assurance story
The test automation story is what makes this engagement stand out in the industry.
Off-the-shelf testing frameworks could not handle the Windows CE embedded platform with the depth and execution-path coverage required for an IEC 61508-aligned industrial product. A bespoke test automation framework was built specifically for this stack.
10,000+ unit tests were defined and developed across more than 100,000 lines of code. The result was 98%+ automated code coverage with deep execution-path validation that gives the team confidence in every release cycle.
The QA track also produced continuous SAFe-aligned delivery visibility: daily burndown reporting, sprint-level progress tracking, and proactive issue identification through structured test result review.
A practical safety-critical software quality model: PROTECT
- P: Platform specificity (does the test framework match the actual deployment environment?)
- R: Rule coverage (are all validation rules tested, including edge conditions?)
- O: Output correctness (are generated manufacturing artifacts validated end-to-end?)
- T: Test depth (is execution path coverage sufficient for safety-critical classification?)
- E: Engineering collaboration (is QA integrated into delivery, not separate from it?)
- C: Compliance traceability (can test evidence be traced to safety standard requirements?)
- T: Technology alignment (does the framework support the embedded platform lifecycle?)
What most safety software articles miss
Most coverage of safety-critical software focuses on standards compliance paperwork. The engineering challenge is different: it is about building systems where incorrect behavior is structurally prevented, not just tested for after the fact.
The TPPR configurator's validation engine embeds correctness rules into the configuration flow itself. Testing confirms they work. The architecture makes them the default.
Frequently asked questions
What is IEC 61508?
IEC 61508 is the international standard for the functional safety of electrical and electronic systems. Systems aligned to it require rigorous safety lifecycle management and evidenced validation.
Why was a bespoke test framework needed?
Windows CE is an embedded platform with limited tooling support. Standard test frameworks either do not run on the platform or do not provide the execution-path coverage depth needed for safety-critical validation.
How is the configuration testing approach different from standard app testing?
Configuration testing must validate combinatorial logic: the full set of valid and invalid configuration combinations, not just individual field validation. This requires intentional test case design, not auto-generated test scripts.
Who led the co-delivery model?
Parallel Minds engineering teams co-worked with Honeywell product and engineering teams across India, the US, and the UK within a SAFe-aligned delivery structure.
Final thought
Safety-critical software engineering is a distinct discipline. The TPPR engagement demonstrates that quality at 98%+ coverage is achievable on embedded industrial platforms when the test framework is purpose-built for the platform and the team treats testing as an engineering capability, not a delivery overhead.
Sources and references
- IEC 61508 functional safety standard overview and guidance
- SAFe (Scaled Agile Framework) delivery methodology documentation
- Windows CE and embedded software testing literature
Methodology note
Test coverage and delivery collaboration details reflect the specific TPPR engagement. Safety software validation requirements vary by product classification and applicable standards.