This paper presents standard quality objectives for models developed with Simulink at different phases of the software development life cycle. This standard, named Model Quality Objectives (MQO), has been defined by a group of leading actors from the French automotive industry and MathWorks, the company that develops MATLAB and Simulink. The purpose of this standard is to clarify and ease the collaboration between OEM and suppliers when sharing Simulink models in the context of embedded software development to drive the production of higher quality and integrity software. OEM and Tier one suppliers that participate in the definition of MQO have shared many concrete use cases when underspecified models or models with insufficient maturity have been prematurely promoted as “ready for coding”. Consequently, higher development effort than planned, bugs and ultimately very difficult conversations related to responsibilities would then take place. Thanks to this feedback and the interpretation of quality and safety standards for software development with Model-Based Design, MQO has defined clear use cases to properly and efficiently develop high quality design models with Simulink based on a set of measurable Model Quality Requirements (MQR). MQO defines four types of design models used at four different phases of the software development life cycle: the functional model, the architecture model, the component design model and the component implementation model OEM and Tier one suppliers involved in MQO have already started to see some benefits when applying some of the concepts presented in this paper back in their organizations. For instance, non-software engineers that want to develop Simulink models can now be confronted to a simple choice. 1. they stop modelling with Simulink early to only validate software requirements (e.g. stop at functional model level) 2. they go down the software V cycle with Model Based Design to produce Simulink models that can generate production code with all the associated constraints to drive quality (e.g. stop at component design model level). In the second case, the organization and the process must adapt to ensure that non-software engineers used to model for prototyping can also develop high quality software with Model-Based Design. This is exactly where MQO can help to drive the change.