AUTOSAR, ECU and embedded software, vehicle communication and diagnostics, SIL and HIL testing, and functional safety support for OEMs, suppliers and EV companies.
Engineers who work the way automotive programs run: requirements to release, with traceability and test evidence at every step.
End-to-end software engineering for automotive systems, from requirements and architecture through implementation, integration and release, with traceability from requirement to test result.
02Firmware and application software for electronic control units, written for the tight memory, timing and safety constraints of embedded automotive systems: drivers, application logic, bootloaders and diagnostics.
03Software on the AUTOSAR standard, CAN and CAN FD messaging, and UDS diagnostic services, so ECUs communicate reliably with each other and with diagnostic and flashing tools.
04Software-in-the-loop and hardware-in-the-loop test environments, so defects are caught before prototypes exist and validated again on real hardware, with automated regression runs.
05Control logic built and verified as models in Simulink and Stateflow, production code generated from those models, and support for the toolchain around them.
06Practical support for ISO 26262 and Automotive SPICE work: hazard analysis input, safety requirements, traceability, and processes that hold up in an assessment.
07Integration of software components from multiple teams or suppliers into a working system, verified against requirements before it moves further down the release pipeline.
08Support for driver assistance features that combine sensor data, decision logic and vehicle control, with the validation work that safety-relevant features require.
We plug into any stage of the cycle, or carry a work package from left to right.
Free for engineers: sign in once with your work email or Google, then use every tool in your browser and download your results.
Enter the bit rate and your messages to see the bus load for classic CAN or CAN FD, with and without worst-case bit stuffing.
Open tool →BITEnter your CAN clock, bit rate and target sample point. You get every valid prescaler and segment setting, best first, with the values to write into the controller registers.
Open tool →DBCTurn raw CAN bytes into physical values, or the other way round. Enter a signal definition, or load a DBC file to decode every signal in a frame.
Open tool →DIFFLoad two versions of a DBC file to see every change between them, or one file to check it for common mistakes: duplicate IDs, overlapping signals, signals outside the payload and ranges the bits cannot carry.
Open tool →ARXMLOpen AUTOSAR ARXML files to browse components, ports and interfaces, check them for common mistakes, or compare two versions to see exactly what changed. A read-only review tool: nothing is generated, nothing is uploaded.
Open tool →ASILRate each hazardous event for severity, exposure and controllability to get its ASIL under ISO 26262, and build a simple hazard list you can export.
Open tool →SPFMEnter your failure modes with FIT rates, safe fraction and diagnostic coverage. You get SPFM, LFM and an estimate of PMHF, checked against the targets for your ASIL.
Open tool →ALLAll thirteen tools, with what each one does and the standards behind it.
See all →Vehicle OEMs and their software teams.
ECU, body, chassis and powertrain suppliers.
EV powertrain, BMS and charging software.
Trucks, buses, tractors and construction equipment.
Compact ECUs, clusters and connected features.
Dedicated engineers · Work packages · Test and validation · Consulting. See engagement models
Modified condition/decision coverage in plain words, with a worked example, the N+1 rule and what to do when a condition cannot be covered.
Read →AutomotiveHow a CAN bit is built from time quanta, why every node needs the same sample point, and how to pick settings that work with your clock.
Read →AutomotiveTwo platforms, two ways of building ECU software. Here is what each one means for the way you plan, build and run tests.
Read →