AV development includes perception, sensor fusion, location & mapping, decision-making & control (or motion planning), embedded, simulation and maybe many system-glue software tools.
L3 planning & control is now expert-based decision system, which basically defines rules to make decision, where model based design(mbd) is a helper.
Waymo mentioned their hybrid decision-making solution, basically Machine Learning(ML) will take a big part of the situations, but still space to allow rule-based solution to take priority.
when consider to ML decision making, mdb will become less useful.
why model-based
Traditional OEMs follow vehicle-level safety requirements(ASIL-D) to develop vehicle products and components, usually can be represented as the V style development, from user requirs, system design, implmenent to test verification.
to go through the whole V process take a rather long time, e.g. for a new vehicle model, it means 2~5 years. Commercial hardware and software(mobile apps) products which has lower level safety requirements, however, can iterate in a quicker frequency.
the safety requirements drive the product development in a very different way, compared to common Internet products, which include more straight-forward programming skills and software architecture mindset. but to satisfy the additional, or should say the priority safety requirements, how to organize the code is less important than how to verify the functions is to satisfy the safety.
so there comes the model-based design, the most-highly feature of which is to support system test and verify at pre-product period.
of course, model-based design should be easily to build up prototype and visualize the system, which is the second feature of mbd, working similar like a microsoft vision e.t.c
thirdly, from design to product, is auto code generation. which means once the design is verified, you don’t need to go back to write code again, but directly generate code from the design graph.
model-based design toolchain is already a whole eco-system, e.g. system design, auto code generator, test tools. and all these tools should be first verified by ASIL-D standard.
Internet AI companies once thought it would be easy to take over this traditional development by Internet agile development, while the reality is they still depends on model-based design at first to verify the system, then back to implement code again, which should be more optimized than auto-generated ones, which is one drawbacks of mbd, as mbd is tool-depended, e.g. Matlab, if Matlab doesn’t support some most updated libs, then they are not in the auto-code, and most time Matlab is far behind the stable version of libs outside.
what mbd can’t do
mbd is born to satisfy safety requirments in product development. so any non safety required product won’t use mbd.
and by nature, mbd is good at turning mathematical expressions to system languages, and logical relations to state flows, so any non-articulatable system is difficult to represent in mdb languages.
in vehicle product development, engine, powertrain, ECU, brake system, ADAS, L3 motion planning, e.t.c have depends heavily on mbd.
but also we can predict, L3+ applications arise, with image, cloud point based object detection, data fusion, SLAM, AI-driven planning, IVI, V2X, will hybrid mbd with many Internet code style.
industry experience: a metaphysics
some friends say mass-product-experience makes him more value than new birds. since industry experience is not transparent, as there is a no clear bar to test the ability/value of the enginer, unlike developers, who can valued by their product, or skills, also the same reason make these guys who stay long in the industry sounds more valued, and they have more likey went through one or many mass product experience.
but at most, industry product depends e.g. vehicle, on teamwork, even the team lead can’t make it by himself, unlike developer, a top developer can make a huge difference, much valued than a team of ordinary ones.