Abstract
Software in modern vehicles consists of multi-criticality functions, where a function can be safety-critical with stringent real-time requirements, less critical from the vehicle operation perspective, but still with real-time requirements, or not critical at all. Next-generation autonomous vehicles will require higher computational power to run multi-criticality functions and such a power can only be provided by parallel computing platforms such as multi-core architectures. However, current model-based software development solutions and related modelling languages have not been designed to effectively deal with challenges specific of multi-core, such as core-interdependency and controlled allocation of software to hardware. In this paper, we report on the evolution of the Rubus Component Model for the modelling, analysis, and development of vehicular software systems with multi-criticality for deployment on multi-core platforms. Our goal is to provide a lightweight and technology-preserving transition from model-based software development for single-core to multi-core. This is achieved by evolving the Rubus Component Model to capture explicit concepts for multi-core and parallel hardware and for expressing variable criticality of software functions. The paper illustrates these contributions through an industrial application in the vehicular domain.
Highlights
Software has become the heart of modern systems across most domains and is enhancing, sometimes even replacing, an ever larger number of mechanical and electrical parts.Communicated by A
There are several modelling languages used in the vehicular domain such as, for example, AUTOSAR [8], ProCom [9], COMDES [10], AADL [11], we focus on Rubus Component Model (RCM) and its extension for multi-core due to the following reasons
Whereas our work focuses on RCM, we believe that the evolution problems that we faced are commonly emerging in the transition of similar languages towards the support of multi-core platforms
Summary
Software has become the heart of modern systems across most domains and is enhancing, sometimes even replacing, an ever larger number of mechanical and electrical parts.Communicated by A. The interaction between the SWCs is clearly separated in terms of data and control flows for facilitating the definition of the control specification, typical of real-time embedded systems, and interactions. Data ports used for modelling data communication while control ports are used for modelling triggering conditions. One important principle in RCM is to separate functional code from the infrastructure implementing the execution model. This allows visualising explicit synchronisation and data access at the modelling level, distinctively. This principle facilitates the analysis and reuse of SWCs in different contexts (an SWC has no knowledge how it connects to other components).
Sign-in/Register to view highlights & summary Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
