ADASDevPro Logo
Product was added to your cart

Cart

When it comes to ADAS development
we see things differently

We believe that the road to a robust system design does not need to take an age, consume every available engineering resource, cost vast sums of money and is only possible by reverse engineering what your supplier is willing to sell to you.

We think that provided what you want to achieve is clear, and the steps that need to be taken are understood, the journey can be a smooth one, allowing you the bandwidth to lead the development phase and not be lead by it; more walk in the park than race against time. The trick therefore is defining what you want to achieve and understanding what you need to do get there. It’s easier than it seems.

What do you want?

Picking the ADAS features that you want is the easy part. The majority of level 1 and 2 features are all well defined, all you really need to do is agree an ADAS road map and an implementation time line. However as I am sure you are already aware, some ADAS features have already been mandated by law and more are due to follow, so pick your features wisely.

When do you want it?

Deciding how quickly you want to implement your new system is your call, but your decision will be primarily down to the business case for developing the feature on your particular vehicle (assuming you understand the development costs), the resource and budget you have and of course the state of the law by the time your prototype or vehicle is ready to go to market; don’t get caught out.

What do you need to do?

Your key objectives are to define what your feature needs to do, how it’s going to do it robustly and safely, and how you’re going to sign it off. In short you need a Feature Description, Functional Safety Concept, a Failure Mode Analysis and a plan to verify and validate it all.

Our Salmon Filled Waterfall Methodology

One of the common mistakes that many development teams make, is to separate out Feature Design, Functional Safety and Failure Mode Analysis into different sub teams and do so at inappropriate times. This has a tendency to result in a bow wave of potentially misguided and misaligned engineering requirements which are cascaded to the Function designers late in the development cycle, leaving the team to decode and then frantically attempt to retrofit requirements into an already implemented feature.

Here at ADASDevPro we prefer to do it all within the same team following our Salmon Filled Waterfall (SFW) methodology. If you understand the V model of systems engineering, then you’ll get our leaping Salmon analogy. It even has bears, but I’ll let you work that one out.

Menu