The electrical and electronic systems (E/E Systems) in the automotive world have been getting increasingly complex over the past decades. New functionality, which is mainly realized through embedded E/E Systems, as well as the growing connectivity (Car2X-Communication), will keep this trend alive in the upcoming years. Additionally, new standards and regulations have been released during the last few years (e.g. ISO 26262), which improve system properties such as dependability, but also lead to an even higher system complexity. Therefore, well-defined development processes are crucial to manage this complexity and achieve high quality products. To accomplish an appropriated guidance through these processes, a tool chain has to be established, which supports each phase of the E/E System development. However, it is not enough to provide a stand-alone solution for the assistance at each phase. A smooth transition of the development artefacts between the different levels as well as their bilateral traceability is crucial. Common approaches utilize tools such as Enterprise Architect or Artisan Studio to model the E/E System design in SysML or a kind of UML2 profile. Usually, several abstraction layers are designed with these tools, starting from the system architectural design down to the software architectural design. Although, in the majority of cases the design should represent a mechatronics-based system, the hardware and the mechanics view are not considered. The aim of this work is to remedy the defficiencies regarding the missing representation of hardware and mechanics artefacts within E/E System design. Therefore, a model-based domain-specific language was developed that describes the system in a more comprehensive way. It makes it easier for domain experts, who are not that familiar with UML or SysML, to create an architectural design. The methodology presented does not ignore existing SysML models, but rather supports them by means of a translator, which converts the DSL model into a SysML representation. As well as the domain-specific language definition itself, a feasible tool support is presented. To showcase that the language definition can be implemented easily in different ways, a custom-made tool written in C# as well as a tool generated from a UML definition is shown.