When it comes to ADAS development
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.
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.