Embedded Perspectives
Compliance & Safety
37 articles tagged with Compliance & Safety.
Test Case Design with the Classification Tree Method: Deriving Unit Tests You Can Defend in an Audit
Ad-hoc test cases can be perfectly good tests and still fail an audit, because nothing on file records why that particular set was sufficient. The Classification Tree Method derives test cases from the input space instead: identify the test-relevant aspects as classifications, partition each into equivalence classes, then combine leaf classes in a combination table. Razorcat implements CTM in the Classification Tree Editor, available integrated into TESSY or standalone. GSAS Micro Systems is the authorized Razorcat engineering partner for India, the UAE and Sri Lanka.
Fault Injection and Robustness Testing for Embedded Software: What ISO 26262, IEC 61508 and DO-178C Actually Ask For
Every safety-related unit contains code that correct inputs never execute: range checks, error returns, timeouts, recovery paths. The functional safety standards require that code to be verified, and they are explicit about how. ISO 26262-6 lists fault injection test as a method for both software unit verification and software integration verification; IEC 61508-3 recommends defensive programming from SIL 2 upward and then concedes that defensive code is exactly what stops teams reaching 100 percent structural coverage. This guide separates robustness testing from fault injection, maps each to the obligation that asks for it, and shows how Razorcat implements automated fault injection in TESSY without leaving instrumentation in production code.
How to Evaluate a Unit Testing Tool for Embedded Software: A Buyer's Framework for Indian Teams
Unit test tool evaluations rarely fail on features. They fail because the tool cannot drive the compiler and debugger the project is already committed to, or because the evidence it produces sits outside the scope of the certificate the assessor asks for. This is a buyer-side framework: six questions, what a credible answer looks like in vendor documentation, and a four-week pilot that measures the answers instead of accepting them.
Is 100% Code Coverage Enough? Statement, Branch, MC/DC and MCC, and What Each One Proves
No. A coverage percentage records which code your tests executed, not whether your tests would notice if that code were wrong. This guide defines statement, branch, decision, condition/decision, MC/DC and multiple condition coverage precisely, sets out what 100% of each does and does not prove, shows what ISO 26262, IEC 61508 and DO-178 ask for alongside coverage, and explains the three things to add: requirements traceability, fault-based testing and robustness cases.
Automated Mutation Testing for Embedded C: The Question MC/DC Coverage Cannot Answer
Structural coverage tells you a line was executed. It does not tell you that a defect in that line would have been caught. Mutation testing closes that gap by seeding small faults into the code, re-running the suite, and counting how many the suite kills. This guide covers mutation operators, the mutation score, the equivalent-mutant problem and cost control, and where seeded faults already sit inside IEC 61508-3. GSAS Micro Systems is the authorized Razorcat engineering partner for India, the UAE and Sri Lanka.
Test Case Quality in Embedded Unit Testing: Why Test Counts and Coverage Are Weak Proxies
Counting test cases and reporting a coverage percentage tells you what your tests touched, not what they would have caught. NASA's tutorial on modified condition/decision coverage puts it directly: coverage is a measure, not a method or a test. A good unit test case traces to a requirement, carries an expected result predicted from the specification, draws its inputs from equivalence classes and boundary values, and stays independent of how the code happens to be written. This guide sets out those four properties, shows how coverage-adequate suites still miss defects, and maps them to ISO 26262 Part 6, DO-178C and IEC 61508 expectations for requirements-based testing.
From Evaluation Licence to Production Licence: How Embedded Unit Test Tool Licensing Actually Works in India
A unit test tool licence is not paperwork at the end of an evaluation, it is a project constraint. Razorcat's own License Management Guide documents the whole arc for TESSY: an evaluation key issued against one host Id and delivered the next working day, a Floating License Server reached over a single TCP port, offline checkouts capped at 3 days by default and 30 as the built-in maximum that cannot be given back, access control lists and usage logging for seat planning, and a separate Continuous Integration licence that the TESSY IDE cannot use. This guide walks that arc and then the part no vendor manual covers: getting the purchase order through GeM, SAP Ariba, Coupa or TReDS.
Unit Testing Fundamentals for Embedded C and C++: Units, Interfaces, Test Drivers, Stubs and What the Safety Standards Demand
In C a unit is a single function. In C++ it is a method, and a method cannot be called without an object. Everything else in unit testing follows from that: the interface is what the unit reads and what it writes, a test driver supplies the startup code and the call, and stubs replace the units around it so the result depends on the unit alone. Razorcat's published TESSY documentation, IEC 61508-3 and the airworthiness authorities all describe the same discipline, and the functional safety standards write it as normative text rather than advice.
The Complete AUTOSAR Verification Chain: AUTOSAR C++14 Static Analysis with Helix QAC, SWC and RTE Testing with TESSY 6
AUTOSAR software component code carries two separate proof burdens: coding-standard compliance across every execution path, and correct runtime behaviour through the RTE. Static analysis and dynamic testing answer different audit questions, so most ISO 26262 evidence packages need both. This guide walks the chain end to end: AUTOSAR C++14 and MISRA analysis with Perforce Helix QAC or Klocwork, then ARXML-driven SWC and RTE testing in Razorcat TESSY 6, then coverage evidence. GSAS Micro Systems is the India engineering partner for both Perforce and Razorcat.
Undefined Behaviour in Embedded C and C++
Undefined behaviour is not a bug your compiler owes you a warning about. ISO/IEC 9899 defines it as behaviour for which the standard 'imposes no requirements', and it signals it in three different ways with, in the standard's own words, 'no difference in emphasis' between them. Which is why code carrying undefined behaviour can pass every test on your bench and still change the day you upgrade the toolchain.
Shift-Left for Safety-Critical Code: Perforce QAC Static Analysis + Razorcat TESSY Dynamic Testing for MISRA, IEC 62304 and FDA Compliance in India
Run Perforce QAC static analysis first to enforce MISRA and clean the code, then Razorcat TESSY for dynamic unit testing and MC/DC coverage. Together they form a complete shift-left toolchain for IEC 62304 medical-device and FDA-regulated software, both from one authorized engineering partner in India, GSAS Micro Systems.
Flex and Rigid-Flex Design Optimization: DFM, Creepage, and Signal Integrity for Indian PCB Teams
Smart and affordable DFM tools for Indian SMB teams designing flex and rigid-flex PCBs. How Siemens HyperLynx, Valor NPI, and automated creepage checking reduce NPI time and prevent expensive re-spins.
Hitex SafeTpal vs In-House Self-Test for AURIX: Choosing the Right Safety Test Strategy
Hitex SafeTpal packages safety software, reference design and services for Infineon AURIX, with the SafeTpack safety manager supplying the runtime self-tests. But when does it make sense to build custom routines instead? We compare both approaches through the lens of ISO 26262 compliance.
ISO 26262 Part 6 Unit Testing Requirements: A Practical Checklist Mapped to TESSY Capabilities
ISO 26262 Part 6 governs software unit design and implementation.
MC/DC Coverage Explained: What It Is, Why You Need It, and How TESSY Achieves 100%
MC/DC stands for Modified Condition/Decision Coverage, the structural coverage metric that requires every atomic condition in a compound decision to be shown by test to independently change the decision outcome.
TESSY + Helix QAC: MISRA Static Analysis + MC/DC Dynamic Testing for Complete ISO 26262 Verification
ISO 26262 Part 6 does not ask for a choice between static analysis and dynamic testing.
Extracting Audio Data from a USB Protocol Trace
USB audio devices, headsets, speakers, microphones, and audio interfaces, transmit audio data as isochronous USB transfers.
India's Automotive Software Moment: Key Takeaways from Perforce's 2026 State of Automotive Software Report
Perforce surveyed 450+ automotive professionals globally. As GSAS Group's executive director and the authorized Perforce partner, here are the findings that matter most for India's automotive and two-wheeler electronics ecosystem.
AI-Assisted Code Remediation for Safety-Critical C and C++
Perforce has extended AI-assisted code remediation across both Helix QAC and Klocwork, delivered through a Static Analysis MCP server that Perforce describes as IDE-agnostic and Code-Assist tool-agnostic, with support for private, air-gapped environments. The fix is proposed by AI. The finding it is fixing still comes from the qualified analysis engine, and a developer approves every change.
MISRA, AUTOSAR, and CERT: Coding Standards Every Indian Embedded Team Should Know
An overview of the coding standards that matter most for Indian embedded teams, MISRA C/C++, AUTOSAR C++14, CERT, and CWE, and how static analysis tools enforce them automatically.
Continuous Development and CI/CD for Embedded Systems in India
Continuous development transforms embedded workflows by automating build, test, and analysis cycles. Indian teams adopting CI/CD with static analysis are shipping safer software faster.
DO-178C Compliance for Indian Aerospace and Defence Software Teams
India's aerospace and defence sector is in the midst of a historic transformation.
Functional Safety for Indian Automotive and EMS: Meeting ISO 26262 and IEC 61508
A practical guide to functional safety standards for Indian automotive, two-wheeler, and EMS teams, covering ISO 26262, IEC 61508, IEC 62304, and the GSAS safety toolchain from Perforce, Arm, Segger, and Razorcat.
Static Application Security Testing: Why 50% of Vulnerabilities Start in Source Code
Half of all security defects originate at the source code level. SAST tools like Klocwork identify vulnerabilities during development, before they reach production. Here's what Indian engineering teams need to know.
Writing Secure C Code: Best Practices for Indian Embedded Engineers
Exploitable coding errors, not sophisticated attacks, are behind a large share of security incidents in embedded systems. Here is how Indian engineering teams can adopt secure C coding practices using proven frameworks and tools.
Software-Defined Vehicles and India's Embedded Software Opportunity
India's automotive sector stands at a pivotal crossroads as software-defined vehicles reshape the industry. Here's what embedded teams need to know to seize the opportunity.
What Is CWE? Understanding Common Weakness Enumeration for Secure Embedded Software
CWE stands for Common Weakness Enumeration, the community-developed catalogue of software and hardware weakness types that names the coding patterns behind recurring vulnerabilities in embedded C and C++.
What Is Linting and Why It Matters for Embedded C/C++ Teams in India
Linting is automated analysis of source code that detects likely errors, unsafe constructs and coding-standard violations without executing the program, and for safety-critical embedded C and C++ it is only the first of three analysis layers.
What Is MISRA? The Definitive Guide to MISRA C and C++ for Indian Automotive Teams
MISRA stands for the Motor Industry Software Reliability Association, and MISRA C is its set of industry-consensus coding guidelines that restrict C to a safer, more predictable subset rather than changing the language itself.
What Is Static Analysis? A Practical Guide for Indian Development Teams
Static analysis examines your code without running it, catching defects that testing misses. Here's a practical guide for Indian embedded and enterprise development teams.
EU Cyber Resilience Act: What Indian Embedded Product Companies Need to Know
The EU CRA takes effect in 2027, impacting every embedded product sold in Europe. Here's what Indian engineering teams must prepare for, and the tools that accelerate compliance.
ISO 26262 Tool Qualification: A Practical Guide for Automotive Teams
Part 8 of ISO 26262 requires tool qualification for all software used in safety-critical development. Learn the TCL classification system and how pre-qualified tools save months.
MISRA C:2023: What Changed and How to Migrate Your Codebase
MISRA C:2023 consolidates MISRA C:2012 with Amendments 2-4. Key changes include new rules for security, updated decidability classifications, and C11/C18 support.
India's Automotive Electronics Opportunity: Building for Bharat and Beyond
India's automotive electronics market is projected to reach $15B by 2028. From ADAS to BMS, here's how Indian engineering teams can compete globally with the right development tools.
The Software-Defined Vehicle Revolution: What It Means for Indian Engineering Teams
The automotive industry is consolidating 100+ ECUs into zonal architectures. By 2030, the automotive software market reaches $462-650B (McKinsey). What this means for Indian engineering teams.
Webinar: Best Practices for Static Analysis in CI/CD Pipelines
GSAS Micro Systems hosted a technical webinar with Perforce Software on integrating static analysis tools into CI/CD workflows and DevOps automation pip...
Live Webinar | Unit Testing and Coverage Measurement for Safety - Critical Applications
This webinar on Razorcat TESSY explains unit testing (What is a unit of a C/C++ program? What is the interface of a unit?) and demonstrates unit testing using the unit testing tool TESSY. Participants learn how unit testing…