Traceable, not just finished
Every deliverable can be followed back to the requirement that caused it and forward to the test that closes it. If it cannot be traced, it is not done.
I am Tsvetan Tsvetkov. For more than a decade I have worked as a systems engineer, and before that as a software engineer, on the teams behind components and tooling in some of the best-selling cars in Europe.
Written down it reads as a list. Requirement specifications decomposed into architecture; functional and technical safety concepts under ISO 26262; hazard analysis and risk assessment, ASIL classification and decomposition down to the element that carries it; behavioural models in Matlab, Simulink and Stateflow, exercised on model-, software- and hardware-in-the-loop benches long before a part exists; traceability that holds from a line in a customer specification through design and code to the test that proves it; and the documentation that has to survive a safety assessment years after the people who wrote it have moved on.
It also means working inside somebody else's process — a vehicle manufacturer's release gates, a supplier's quality system, a programme that will not move its start of production because a workstream is late. Clean engineering that arrives after the gate is worth nothing.
Lived, the work is quieter than the list. A decade of it ends as a few hundred milliseconds of behaviour nobody is meant to notice: a warning that comes at the moment it is still useful, a display that stays readable exactly when it matters, a function that, when it fails, fails in the direction that is safe. Today a very large number of European drivers rely on that work every time they start the engine, and not one of them will ever know it is there.
A four-course programme from the Massachusetts Institute of Technology covering the architecture of complex systems, models in engineering, model-based systems engineering for documentation and analysis, and quantitative methods — the formal apparatus behind the way every engagement here is structured.
Computer architecture, microprocessors, operating systems, semiconductors and algorithm analysis — the layer underneath the models, which is where safety-critical software eventually has to run.
Every engagement is run so that the uncomfortable findings arrive while they are still cheap. Analysis before modelling, simulation before hardware, documentation written as the work happens rather than reconstructed before an audit.
Not promises — working practices, and you are welcome to check them against anything delivered.
Every deliverable can be followed back to the requirement that caused it and forward to the test that closes it. If it cannot be traced, it is not done.
I work inside your gates, your templates and your toolchain, not beside them. Integration is my problem, not yours.
Where an analysis is uncertain, the uncertainty is written down and carried forward rather than smoothed over in a status report.
At ZETOSON we analyse it and turn it into a solution. Book a no-obligation meeting with our team.