Automotive Testing Services for HIL, ECU Validation and Cybersecurity

A controller should respond correctly when a sensor fails. A software update should leave the ECU in a defined, recoverable state if power is interrupted. A production test should identify a faulty unit before it leaves the line.

These are different engineering challenges, but they share the same need: testing that produces clear, repeatable evidence.

Piest Systems provides automotive testing services for OEMs, Tier 1 and Tier 2 suppliers, bringing together embedded software expertise, hardware understanding, test automation and integration support. Our focus spans HIL testing, verification and validation, automotive cybersecurity, software-update validation and end-of-line testing.

We also support unit testing, static analysis, coding-rule checks, dynamic testing, structural coverage, diagnostics and functional safety verification. Each engagement connects the required checks to the system being developed, the available test environment and the evidence needed for delivery.

HIL testing services: exercise real controllers under demanding conditions

Hardware-in-the-loop testing connects a real ECU to a real-time simulated environment. It allows engineers to apply controlled inputs, observe outputs and repeat scenarios that would be difficult to reproduce consistently in a vehicle. HIL background: dSPACE.

Our HIL testing services focus on functional behaviour, integration, robustness and fault response. Depending on the ECU and bench configuration, the work can include:

• Sensor and actuator simulation, including analogue, digital, PWM and frequency interfaces.
• Restbus simulation for unavailable controllers and communication partners.
• Normal, boundary and abnormal operating scenarios.
• Missing or implausible inputs, communication timeouts and recovery behaviour.
• Startup, shutdown, sleep, wake-up and repeated reset sequences.
• Controlled power interruptions and voltage variations using suitable equipment.
• Open-circuit and short-circuit tests where the bench has appropriate protected fault-injection hardware.
• Long-duration execution, automated regression and comparison between software versions.

For a gateway, the test may check whether a missing message produces the specified fallback behaviour. For a body controller, it may check how outputs respond to a failed input. For a battery-management controller, simulated signals may be used to exercise monitoring and protective responses, subject to suitable models and interfaces.

The environment is part of the test result. We establish the plant-model assumptions, I/O mapping, signal scaling, timing, loads and measurement method before interpreting a failure. Software simulation alone cannot reproduce every electrical fault, and a bench test does not replace all vehicle-level validation.

Automotive verification and validation services in Automotive Testing Services

Verification asks whether the implementation meets its specified requirements. Validation asks whether the resulting system fulfils its intended use in the relevant operating context.

Piest Systems structures automotive verification and validation services around both questions. The work starts with requirements review and testability: what must the function do, under which conditions, and how will the result be judged?

The agreed scope can include software-unit verification, software integration, ECU integration, system-level testing and validation support. Model-in-the-loop, software-in-the-loop, processor-in-the-loop and HIL environments are selected where appropriate and available. They address different risks; they are not interchangeable labels for the same test.

We connect requirements to test cases, execution records and defects. When a requirement or software version changes, that traceability helps identify which tests need review and which results must be regenerated.

For OEM teams, the priority may be behaviour across multiple ECUs. For Tier 1 suppliers, it may be release evidence and customer acceptance. For Tier 2 suppliers, it may be component correctness and integration readiness. The scope follows that responsibility.

Automotive cybersecurity in Automotive Testing Services

Connected controllers must handle unexpected and unauthorised inputs as well as valid requests. Security testing examines whether the implemented protections behave as intended and where weaknesses may remain.

Piest Systems offers automotive cybersecurity testing services with scope derived from the agreed architecture, threat analysis and cybersecurity requirements. Activities can include:

• Diagnostic access-control and authentication testing.
• Secure-boot and software-image authenticity checks.
• Rejection of modified, unauthorised or incompatible update packages.
• Replay protection and freshness handling for protected communication.
• Robustness testing and fuzzing of agreed protocol interfaces.
• Assessment of exposed services, interfaces and relevant software dependencies.
• Authorised penetration testing within defined targets and rules of engagement.
• Retesting fixes and recording unresolved vulnerabilities.

For example, rejecting an invalid update is only part of the requirement. The ECU should also remain in the specified state, preserve required data and support the defined recovery process.

Testing can contribute evidence to a project’s ISO/SAE 21434 cybersecurity engineering activities. That standard addresses lifecycle cybersecurity risk management; a set of passing security tests does not, by itself, demonstrate complete conformity. ISO/SAE 21434 overview.

Findings should identify the affected configuration, reproduction conditions, impact, mitigation status and retest result. Sensitive evidence is handled through the customer-approved process.

OTA, FOTA and BOTA testing: validate the complete update journey

Over-the-air (OTA) testing follows the update from delivery through installation, activation and post-update behaviour. Firmware-over-the-air (FOTA) testing focuses on firmware updates within that workflow.

We also scope BOTA testing against the customer’s definition of the term. Where BOTA means bootloader-over-the-air updating, particular attention is given to the update chain, boot recovery and the protected mechanisms that must remain available after an interrupted operation.

Update-validation scenarios can include:

• Package authenticity, integrity, compatibility and version checks.
• Preconditions such as vehicle state, available storage and power level.
• Interrupted downloads, network loss, retries and resume behaviour.
• Reset or power loss during erase, programming, verification and activation.
• Multi-ECU update dependencies and mixed-version conditions.
• Recovery to an authorised known-good image where the architecture supports it.
• Rejection of prohibited downgrades according to the anti-rollback policy.
• Preservation or migration of calibration, configuration and nonvolatile data.
• Update status reporting and post-update functional regression.

Recovery and security must agree. A recovery mechanism should not provide a route to install a version that the security policy prohibits.

For bootloader updates, tests must reflect the actual architecture: protected recovery code, redundant storage or another defined recovery strategy. A successful firmware update alone does not demonstrate that the bootloader itself can be updated safely.

EOL testing for production readiness and traceability

End-of-line (EOL) testing checks each manufactured unit against an agreed production acceptance sequence. Its purpose differs from development validation: the test must detect relevant manufacturing and configuration defects consistently within the available production cycle.

Piest Systems supports EOL test-sequence development, automation and integration with the agreed fixture and manufacturing environment. Typical checks can cover ECU identification, software-version verification, programming status, communication, I/O operation, diagnostic health and calibration or configuration readback.

Where included in the scope, the workflow can link results to serial numbers and manufacturing records. Retry and retest rules should preserve the original result so repeated attempts do not hide an intermittent defect.

We also consider the test station itself: fixture checks, measurement limits, reference units, access control and version management. A false pass can release a defective unit; a false fail can create unnecessary rework. EOL testing complements development V&V rather than repeating the entire development test suite on every unit.

Static verification: MISRA, Polyspace and Astrée

Static analysis examines software without executing the target program. It complements reviews of requirements, design and code, and can expose problems before runtime testing begins.

Our static-verification scope can include MISRA C or MISRA C++ checks against the agreed edition, coding-rule compliance review, defect analysis, findings triage and deviation documentation. An automated report is an input to compliance assessment; not every rule or project obligation can be resolved by running a checker.

Tool selection depends on language, compiler configuration, analysis objectives and available licences:

Tool or activity	Role in the verification workflow
Polyspace Bug Finder	Static defect detection, coding-rule checks and quality findings
Polyspace Code Prover	Formal static analysis of selected runtime-error properties under configured assumptions
Astrée	Abstract-interpretation-based static analysis of runtime-error properties in supported programs
Reviews and deviation handling	Assess findings, manually reviewed rules, rationale and corrective actions

Polyspace’s static-analysis products are distinct from Polyspace Test, which supports executable testing. This distinction matters when specifying deliverables and tool requirements. MathWorks Polyspace product family.

Analysis results depend on the configuration and assumptions. We review items such as target data sizes, compiler options, external interfaces and input constraints so the findings correspond to the intended build. A proof concerning selected runtime errors is not a proof of complete functional correctness.

Unit testing, dynamic testing and structural coverage

Dynamic testing executes software and observes its behaviour. Piest Systems supports requirements-based unit tests, integration tests and runtime checks in suitable host or target environments.

Unit-test work can include test-harness development, stubs and mocks, boundary values, invalid inputs, state transitions and expected error responses. Target execution adds evidence about behaviour that depends on the processor, compiler and runtime environment.

Coverage analysis may include statement, branch or decision coverage, and modified condition/decision coverage (MC/DC), as required by the verification plan. We review uncovered code and determine whether additional tests, requirement clarification or a justified exclusion is needed. High coverage alone does not show that expected results were correct.

Polyspace Test is an option for C/C++ test development, execution and coverage measurement where its supported workflow fits the project. Astrée and Polyspace Code Prover belong in the static-analysis workstream rather than being described as dynamic test-execution tools. MathWorks Polyspace Test.

Runtime activities can also examine response time, resource use, repeated operations and recovery. Instrumentation effects and differences between host and target execution are recorded where they affect interpretation.

ISO 26262 testing services and functional safety verification

Functional safety testing needs to demonstrate the specified response to relevant faults, as well as correct behaviour during normal operation. ISO 26262 addresses functional safety of automotive electrical and electronic systems; the applicable work depends on the item, lifecycle activities and safety requirements. ISO 26262 overview.

Our ISO 26262 testing services focus on engineering verification and test evidence within the customer’s safety plan. The agreed work can include:

• Tests derived from allocated software and technical safety requirements.
• Verification of diagnostic monitoring and fault-handling mechanisms.
• Controlled fault injection and checks of the specified safe or degraded state.
• Measurement of detection and reaction timing against allocated budgets.
• Robustness tests, boundary checks and recovery verification.
• Software-unit and integration evidence, including required coverage analysis.
• Traceability, anomaly tracking and verification reports for project review.

For example, a test may examine whether a detected signal fault triggers the specified protective response within its timing requirement. The evidence must record both the injected condition and the observed response.

The required methods, independence, coverage and tool-confidence activities follow the applicable ASIL and project plan. Testing services support that work; they do not constitute an ISO 26262 certificate or replace the complete safety lifecycle and assessment process.

Diagnostic, communication and functional testing

Diagnostic testing checks service behaviour and its interaction with ECU state. Our scope can include UDS sessions, security access or authentication where implemented, data identifiers, diagnostic trouble codes, routines, negative responses and timing, over the transport interfaces used by the project.

Communication validation can examine CAN, CAN FD, LIN, FlexRay or Automotive Ethernet where the agreed environment supports them. Tests address message content, timing, timeouts, gateway behaviour and recovery. DoIP and SOME/IP are considered at their appropriate protocol layers.

Functional testing follows the requirements through normal and abnormal operating states. Startup, shutdown, memory retention, sleep and wake-up, calibration changes and input/output behaviour can be assessed individually and in combination.

For AUTOSAR integration, tests can follow an application request through the RTE, basic software and driver interfaces. A failure that appears in diagnostics may originate in transport handling, scheduling, memory services or configuration. Our development and integration support helps investigate those connections and retest the correction.

Automotive test automation that remains useful after delivery

Repeated manual testing becomes difficult to maintain as software versions and product variants increase.

Our approach to automotive test automation starts with the tests that are stable enough to repeat and valuable enough to maintain. Those may include a build smoke test, diagnostic checks, communication checks or regression tests for previously fixed defects.

The workflow can include test setup, execution, log capture, result evaluation and reporting. Where the customer’s infrastructure supports it, automated tests can be connected to build and continuous-integration workflows.

Automation needs trustworthy verdicts. A failed test should be distinguishable from an unavailable bench, an incorrect configuration or a script error. Recording those differences helps engineers spend their time on the right problem.

Practical use of AI, with engineering review

Piest Systems uses AI-assisted engineering to help with repetitive work such as drafting test cases, preparing scripts and analysing logs, within the agreed project workflow.

The value comes from how those outputs are checked. Suggested test cases must be reviewed against the requirements. Generated scripts must be validated in the intended environment. An AI-generated explanation of a failure must be tested against the evidence.

Before AI is used with project information, the permitted tools and data-handling rules should be agreed with the customer. Engineers remain responsible for test design, verdicts and delivered findings.

Together with reusable test assets and suitable in-house tools, this approach is intended to reduce avoidable manual effort. Cost and schedule estimates are based on the actual scope, dependencies and acceptance criteria.

What your team receives

The deliverables are agreed at the start of the engagement. A typical work package can include:

• A test plan with scope, assumptions, environment details and acceptance criteria.
• Applicable HIL configurations, static-analysis findings, coverage records, cybersecurity findings or EOL results, according to the work package.
• Test cases linked to the applicable requirements.
• Test scripts and configuration assets, with ownership and licensing agreed.
• Execution results with relevant logs and version information.
• Defect reports with reproduction steps and supporting evidence.
• Retest results and a summary of remaining gaps or limitations.

The purpose is to give your team an understandable record of what was tested, what passed, what failed and what remains unresolved.

Start with a focused proof of concept

If the environment is unfamiliar or the problem is difficult to reproduce, a focused proof of concept can establish a practical starting point.

For example, the pilot might establish a HIL regression sequence, validate interrupted-update recovery, review a static-analysis baseline or automate a production EOL check. We agree on the inputs, test conditions and success criteria before execution.

The result helps determine what can be reused, what additional setup is needed and how to estimate the wider work package.

For an initial discussion, share your ECU or software function, development stage, relevant interfaces, main testing challenge and target milestone. Confidential specifications and source files can follow through an agreed secure process.

Need support with HIL, verification and validation, cybersecurity, update testing or EOL automation? Discuss your project with Piest Systems at piestsystems.com.

Frequently asked questions

Can you support a specific testing task rather than an entire programme?

Yes. An engagement can focus on a defined activity such as diagnostic validation, integration debugging, test-script development or a regression work package. The scope and deliverables are agreed before work begins.

Can testing begin before the final hardware is ready?

Some software and interface checks can begin using suitable software environments, mocks or simulation. Tests that depend on the physical controller still require the appropriate hardware. The test plan identifies that distinction.

Can you work with our existing test environment?

We review the available tools, interfaces, licences and access arrangements during scoping. That review establishes whether work can proceed in the existing environment and what adaptation is required.

How are cost and delivery time estimated?

Estimates depend on the requirements, test count and complexity, environment readiness, automation needs and reporting expectations. A focused pilot can help reduce uncertainty before a larger commitment.

What does the service cover?

This service focuses on embedded software and ECU testing. Physical vehicle durability, crash, EMC, environmental and homologation testing require separate facilities and scope; they are not included in this offer by default.