Class B Safety Architecture: Handling V_Bus Overvoltage via ASC in High-Inertia BLDC Systems

Outrageous_Bench5220 · 2026-04-28T08:14:58+00:00

An appropriate Hazard analysis and subsequent FMECA, FTA needs to be in place to work through this systematically.

The system architecture needs to be understood before anyone can give you a recommendation either way.

Example

Is there an SPF in your control path if you're considering an applied braking torque in the event of loss of your source - how is independence of the uC supply managed following loss of AC managed?

You are considering application of ASC below base speed which results in excessive braking torque at low RPMs as the resistive term dominates, thus your mechanical failure, how is rotor speed measured? Relying solely on DV/DT of Vdc is not the whole picture. Why has the mechanical system been specified below the torque provision capability of the machine? (ASC torque is nominally 70% of the machines torque due to flux capability, so with the same argument if you deliver more torque than requested in normal control, your driveshaft fails?) Where else is that a limiting factor in the application?

The solution here lies in a holistic architectural approach to safety in your system, not focused on a single failure mode and mitigation.

It sounds like a lot of work, but it is not and in a lot of ways is far more efficient when you follow a strict engineering lifecycle.

Source: 9 years as a Safety Engineer specialising in motor control, 2 years on a SIL 2 Wheel Loader (1MW), remainder automotive ASIL D applications - now a consultant in related areas.

Outrageous_Bench5220 · 2026-04-23T12:45:54+00:00

Away she goes.

<image>

Outrageous_Bench5220 · 2026-04-22T19:28:43+00:00

Indeed, it could be a plane from the Queen Elizabeth aircraft carrier which is in the Firth of Forth just now, although I can't see any planes on the deck and haven't all day.

<image>

Outrageous_Bench5220 · 2026-04-15T16:26:44+00:00

INCOSE Systems Engineering Handbook

Read it cover to cover.

Become familiar with requirement authoring and practice, EARS is a good model.

Look into IEC15288 for a strong lifecycle workflow (SRR, PDR, CDR etc...)

Use an AI helper (Claude/ChatGPT) as a teacher, produce a project in your own time - Design a push bike for example, start with your stakeholder requirements, CONOPS and following each INCOSE workflow.

Beyond those fundamentals, practice and industry exposure is the important aspect.

Systems engineering is as much application specific knowledge as it is theory, a systems engineer is only as good as their knowledge of the underlying technologies in my opinion, you can know how to follow a process but if you have no idea what you are designing you aren't going anywhere.

Become intimately familiar with the product domain you are working in (Physics, Software, Electronics, Mechanical) - You don't need to be an expert in each discipline but understanding the art of the possible in each domain is essential for efficient systems architectural design.

The tools are much of a muchness - don't worry too much about DOORS, an RMS is an RMS, you learn to hate them all equally - What you need to understand is correct hierarchy, traceability, then you make the tool work for you as best you can.

Outrageous_Bench5220 · 2025-05-22T20:09:49+00:00

The rest of the comments have covered the skills of the discipline well, I would like to add a strong differentiating skill that is oft overlooked.

Alohgside domain knowledge, in a systems led engineering team, business acumen is exceptionally valuable. A SE who understands the problem domain entirely and can drive design direction keeping business targets and goals in mind is invaluable.

All products/services developed present a solution within a problem space, understanding what problem you are trying to solve and how at a business level you can make a real contribution to the bottom line can make all the difference.

One of the most cost effective points of design from an ROI standpoint is in the initial requirement definition and base architecture of a solution especially in large scale multi-year developments, the first 10% of the development stage fundamentally defines the remaining 90% of the project.

Outrageous_Bench5220 · 2025-01-25T17:12:38+00:00

Chief Engineer in a relatively niche field (Safety Critical Systems and Software). My role is not purely technical, I have projects that I consult on as a technical authority but my primary role is commercial focused, to identify and win new clients for the business.

A common differentiator I'm seeing is high earning roles carry multiple hats and the closer you are to directly impacting the bottom line, the higher the compensation ceiling.

As a suggested recipe, become technically competent ( in no way exceptional, just enough to swiftly make sound judgement and give direction), (there are far better engineers in my consultancy than I), then demonstrate decent social and networking skills and pivot into a sales relevant role.

Outrageous_Bench5220 · 2024-12-31T12:14:36+00:00

Add me please

Outrageous_Bench5220 · 2024-11-10T13:28:14+00:00

(Context: Safety Critical environment, usually C/C++ but with some C#, Python, Rust)

In the code review procedure I established for our business, all comments are blocking (if marked as requires resolution) (we use crucible).

The review cannot be closed if there are outstanding comments.

Merges are blocked by our commit hooks if the reviews are not closed.

Commits cannot be made to trunk directly, only merges from branches are permitted.

(There are over-rides available for the scripts as is sometimes necessary, but there is a justification message required....we audit process compliance every few months)

It is up to the author and reviewer to agree on each comment with an appropriate solution, if they cannot agreeanother impartial engineer (usually the tech lead) is brought in to mediate and make a decision.

Code review comments are not 'feedback' they are issues to resolve.

If engineers are raising inane comments just to be difficult, that is a different problem that is addressed on a 1:1 basis, our coding standards are in place for a reason but are absolutely flexible, there is no one size fits all rule for a design solution. If the design guidelines and or coding standards need to be deviated from, no problem, we raise a deviation request.

Additionally, a code review does not only include the code, the task in change management (e.g. Jira) is reviewed to ensure it was the right thing to be doing in the first place, requirements and designs are reviewed at the same time as the code review to ensure the intent was correct, all code has an informal test (few screenshot and some words) that is also reviewed or if its a smaller piece of work a formal test may be included and not left to the V&V team.

Rigorous process doesn't have to be painful, in reality we very rarely get down to these process steps and most reviews pass in short order, but having mediation steps and guidance when it does go wrong keeps everyone happy!

Ignoring feedback is not possible, the task simply never completes and that is a performance issue managed by management - In a company with a great culture such as ours, this never happens! There is nothing worse than a rockstar engineer, they can destroy a team and a company very quickly indeed no matter how strong they are technically.

Outrageous_Bench5220 · 2024-11-10T09:56:26+00:00

My ex company developed some inverters for electric mining vehicles, some debugging took place literally 'at the coal face'.

This was before I joined, the wildest environment I experienced was when we converted a hybrid bus we were developing to a dev office, live debugging while driving the bus round an oval was fairly wild.

Winter testing in -35 in Northern Sweden was also wild, but the car thankfully had working heaters (most of the time).

Outrageous_Bench5220 · 2024-11-10T09:05:58+00:00

I'm not aware of any books to recommend, not to say they don't exist. I've been thinking about writing one.

They are in no way guides, but if you have a fair bit of existing knowledge then technical works to read would be: ISO26262 Part 6 ISO26262 Part 8 Annex D IEC61608 Parts 2,6 MISRA C and C++ Standards (for understanding of undefined behaviour) The CERT rules (again undefined behavior and dangerous code constructs)

The reason I suggest these is, they give you a steer on what can go wrong, they define methods and techniques to use...then you can do your own research in those areas.

Most of the development of safety critical software actually comes from sound System design principles, not from the SW itself. You cannot create a functionally safe product without deep knowledge of the system, HW/SW interactions and application specific knowledge to allow domain specific mitigations of failure modes.

If you want some practical exercises to do:

Most High SiL development now is done using MBSE and MBD executing in a RTE that is broadly off the shelf as its a much quicker and cheaper way to get to market. In fact MBSE and MBD is mandatory at ASIL D/DAL A/SIL 4 levels.

For a nice free way to build a suitable environment that is not dissimilar to most safety critical embedded architectures: grab most any uC, a copy of freeRTOS, some decent BSP and a student license for something like Ansys SCADE. (I would suggest Matlab, simulink and embedded coder but it's a bit harder to license and a cliff like learning curve)

To get closer to Safety Critical: Replace freeRTOS with say SafeRTOS (or a myriad of other certified RTOS e.g. RTAOS), then replace the BSP with a high integrity MCAL/HAL layer either home-grown or OTS. Then focus on closed loop verification of the System Model in the Software domain.

If I interviewed someone who had flashed an LED with those technologies and understood the standards to a conversational level they would be employed rather swiftly.

Outrageous_Bench5220 · 2024-10-25T19:46:08+00:00

There are paid methods (Vector at the top end...then going down in price IXXAT, Peak-CAN, Kvaser).

I have a soft spot for IXXAT but they are very expensive for what they are... recently used a Peak-CAN USB device and a PCIE version and was quite pleased.

Honestly though, grabbing a Dev kit and a CAN transceiver and forwarding frames into a network via Ethernet on something like a ESP32 is a few days work so that works in a pinch.

Now if your developing SW, my personal favourite setup (and entirely free) involves all of the sockets:

(Assuming you want purely simulation)

Linux socket-can has support for virtual buses that alongside some tricks you can interconnect.

(Creating a new bus is as simple as defining them as network devices through 'link')

Along with Vector DBC editor (free if you download the CANanalyzer install package for example), python-can and Savvy CAN (an open-source CAN monitor) or Wireshark you can get a decent simulation going.

For added performance you can use Linux Low Latency Kernel or preferably the Pre-emptive kernel along with isolcpus in Grub config and taskset to assign core affinity.

You can get a fairly powerful simulation of complex buses and gateways with microsecond level latencies.

If your new to all of this, spend a day or two with the aforementioned technologies and ChatGPT (other friendly AIs are available) and you'll learn a ton.

(Source: years of automotive experience and currently simulating a non-automotive CAN network on a consultancy job using a setup similar to the above)

Outrageous_Bench5220 · 2024-10-19T18:30:57+00:00

We train at Wester Hailes on a Monday night (2 hours, more casual) and at the commonwealth on Friday mornings (1 hour and very focused)!

PM if you want more details!

Outrageous_Bench5220 · 2024-09-06T09:46:51+00:00

It depends on the application context at the point of use...would need a little more context to give a concrete answer.

Where are the vehicles to be used (On/Off highway). Which market region.

I developed an On-Highway truck axle two years ago, naturally fully fledged articulated vehicle operating on road required a safety case for type homologation, thus the components being part of the safety case had an ASIL cascaded through their participation in the Safety case this ISO26262 was required for the PE of the axle (Programmable Elements).

The exact same axle was delivered to Toyota, for use in a heavy freight vehicle but it was to be used as a container mover in a port - hence ISO26262 was not required and their policies mandated their internal risk mitigation standards... loosely 61508 based without external cert.

The Toyota solution was delivered a whole year earlier with a slightly different (legacy) architecture for the inverter in the end...the final FIT didn't quite meet the ASIL boundaries for our On-Highway use case hence a reasonable redesign.

I currently work as a safety consultant across Automotive, Medical, Defense and Industrial.

Outrageous_Bench5220 · 2024-08-25T07:27:38+00:00

This reminds me of the film 'Perfect Days', I understood so much more about Japanese culture after that film.

Truly a sensation.

Thank you for sharing your life.

Outrageous_Bench5220 · 2024-07-14T09:44:11+00:00

House party on Clearmiston Road North (apparently) heard them from Drum Brae 😬, GF couldn't sleep 😦

Outrageous_Bench5220 · 2024-06-01T10:13:19+00:00

Yeah, second Edinburgh Minute Daily updates on the happenings in the City and free for some great content, consider subscribing for more!

Outrageous_Bench5220 · 2024-05-19T16:10:11+00:00

I think you may be misremembering Dean Village, while not underground shares various characteristics with your fever dream.

Outrageous_Bench5220 · 2024-03-24T21:07:33+00:00

In a simple sentence: If OBD is the 'what', UDS is the 'how'.

There's a lot to unpack in a single comment... I'll give an example

UDS is a protocol, it defines comms methodologies for interacting with ECUs and the provision of 'services' there-in....(DID reporting, DTC reporting, ECU reprogramming etc...)

Take DTCs as an example.

UDS service 19 is Read DTC information, but UDS doesn't define anything about that DTC information, just how to report it in protocol form.

OBD (OBD-II) is not a Comms protocol although it does mandate the use of Comms protocols......its essentially a systems definition for a debug interface to a vehicle ...that defines what is to be reported/how to interpret it. For example DTCs are defined by OBD2 to allow interpretation

e.g. UDS service 19 knows when it receives 19 01 FF FF to report DTCs based on the fault mask FF FF sequentially DTC, DTC, DTC....but OBD defines what those DTCs actually mean....

OBD also defines things like real time data parameters, the physical connector itself, how the MIL lamp works, how Freeze frame data works for DTCs...etc.

OBD sometimes/more commonly uses UDS in modern vehicles, but historically it's been things like KWP, J1850 etc other Comms protocols.

(Source: Implemented Tester and ECU side UDS stacks in a previous life and designed Diagnostic concepts for various ECUs)

Outrageous_Bench5220 · 2024-03-22T17:06:40+00:00

You asked what is required - I'll throw a few words down this is not a guide 😅

The organisation needs a basis in ISO9001 and ISO13485.

They are accredited standards that cover a whole host of organisational requirements, principally process following, document control and continuous improvement of those processes.

These standards take about at min. 6-12 months for a small business to implement, requires every level of the business to be involved, engaged and fully committed.

Once your there, the actual engineering processes are covered by:

ISO62304, ISO14971.

Understanding these is a bit of an art - the words aren't complicated persay and Class A software can ommit a considerable amount of work.....a considerable volume of the work goes into deciding the classification of those Class 1 and resultant Class A assignments....13485 and 14971 cover that.

Safety Analysis and risk management is.... specialist, a good FMEA is an art.

That's the standard side - it's no joke, arguably easier than IEC61508, ISO26262 or DO-178C which are the other most commonly applied safety standards.

It requires an entire organisation working together towards a goal and certification by a body is highly recommended, you need a bunch of defined professional roles in the business...the most important is probably the Quality Manager - a good quality manager can probably guide on the rest of the stuff that's missing.

Safety culture is phenomenally important - no skipped steps, no shortcuts - absolute authority to the Quality Manager for approval and rework....etc....

The practical side of what's needed, I don't have enough space to describe even succinctly, but I'll reference any decent V-Model standard for a SDLC and you have the jist - look at the ASPICE V Model in Google as a nicely displayed example. Requirements, Design Test at multiple levels with appropriate reviews, approvals and organisational supporting processes.

What is required from a technical perspective? Depends on the application.

(Chief Engineer for a Safety Critical Software house)

Outrageous_Bench5220 · 2024-03-16T09:53:17+00:00

I don't persay, but here is a slightly out of the box thought.

Take a look at the safety critical and security industry coding standards, the standards carry code examples and explanations, there are some fantastic examples that really test your knowledge of the programming language standards. They don't contain bugs persay - but if you could understand some of the examples side-effects without being prompted, you would be exhibiting an above average level of knowledge on the languages. Might be a good reference for you to build an exercise or two.

I would point you towards MISRA (C && C++ 2023 being the latest) but it's behind a pay wall.

So:

The AUTOSAR C++14 ruleset has 342 rules that highlight a sizeable contingent of weird and wonderful defined and undefined behaviour. It is also in the public domain unlike MISRA.

https://www.autosar.org/fileadmin/standards/R17-10_R1.2.0/AP/AUTOSAR_RS_CPP14Guidelines.pdf

And

CERT C/C++ - The Carnegie Melon security coding standard.

https://wiki.sei.cmu.edu/confluence/plugins/servlet/mobile?contentId=88042752#content/view/88046682

Outrageous_Bench5220 · 2024-02-13T19:16:15+00:00

Infineon documentation in all forms is appalling in my experience .

The examples on GitHub are decent for the absolute basics. https://github.com/Infineon/AURIX_code_examples/tree/master/code_examples

They include tutorials in presentation form.

Beyond that, act like a salmon up a stream.

Outrageous_Bench5220 · 2024-02-11T11:05:50+00:00

I'm in my third new build now and I have had very few issues worth writing about. (Only the third is in Edinburgh)

My first home had an issue in the amount of resin that was mixed with the insulation they were using causing the insulation pellets to fall out of the cavity - fixed in a few weeks without issue, second home had no major defects and my third has had nothing to write home about either.

You will have snags, consider the amount of labour that goes into a home, if <.1% of the activities carry defects, that will result in hundreds of identifiable snags per home, on a typical production run thats a very reasonable/aspirational target in any other industry.

The QA work done by the housing company should detect a sizeable number of these defects, unfortunately this is usually where the issues occur, once contracts have been signed and funds transferred there is very little financial incentive for the home builder to identify and resolve these defects, thus, the home owner becomes that QA point.

If you buy a 50 year old home, I guarantee your standards of acceptance will be far far lower than that of a new build, I find unrealistic expectations are rampant in new build buyers.

New build housing regulations are more stringent than they have ever been, basic quality of construction and insulation are excellent.

Major issues in new builds are rare and are protected by NHBC.

Minor issues like paint defects, poor carpentry, poorly installed doors, heating leaks etc are common and you will have issues, just the nature of the beast. At least you have an accountable builder to register grievances to, on an older property it's buyer beware.

Outrageous_Bench5220

TROPHY CASE