PARTS THEREOF

TECHNICAL FIELD

The present disclosure relates to a computer-implemented system and method, a computer program product for performing said method, and a physical broker device. More specifically, the present disclosure describes simulation of functionalities of a physical vehicle or parts thereof.

BACKGROUND

Testing is a fundamental part of the automotive manufacturing process. Leaps in the technological advancement surrounding the automotive industry is as of today largely realized by software and electronic (sub-)systems. Without meticulous testing of said software, electronic systems and related control functionalities, subsequent component failure may lead to loss of human lives or at the very least substantial financial damages.

Conventionally, automotive testing involves a sequence of well-defined test phases that are to be followed during the manufacture of a vehicle. The test phases may include planning, analysis and design, implementation and execution, evaluation and reporting, and finally closure activities. Moreover, each test phase may have its respective sub-phases and test-related activities to be followed. A plurality of different testing methodologies have been suggested and is currently employed in the automotive industry, such as the “V-model” or the waterfall model. In recent years, agile methodologies and adaptations of the conventional models have been suggested to make the testing process more flexible. However, concerning the automotive industry, it has been shown difficult to transition from the conventional static testing processes into more agile methodologies due to various technical reasons and limitations. Compared to other technical areas that are less dependent on physical components than in the automotive industry, agile software testing processes are significantly easier to implement. While performing testing of whether vehicle components function as intended in a vehicle, said components have to be designed, ordered from suppliers, and physically assembled in something that in the present disclosure will be referred to as a box vehicle. The box vehicle can be interpreted as a “vehicle” comprising all electronic units required for a system or subsystem in said vehicle to be able to functionally operate in a physical (real) setting, without taking into consideration physical restrictions such as component dimensions, sizes, or otherwise structural dependencies. For example, the box vehicle includes electronic control units (ECUs) and various control networks, but not the vehicle body, tires and windshields. Testing of the box vehicle therefore aims to test functional features rather than structural features. Unfavorably, this type of testing depends on all vehicle components already being designed, ordered and assembled into the box vehicle before any testing thereof can be performed. This involves obvious drawbacks related to time and cost aspects upon discovering that certain vehicle components in the box vehicle may be incompatible with one another for various reasons. Hence, the testing procedure would have to be halted, and maybe even reverted and/or restarted with additional, fewer or modified vehicle component adaptations, while waiting for other components to be designed, ordered and/or assembled. This is a very static and cost-inefficient testing procedure.

In light of the above observations, the present inventors have discovered an exceptionally flexible and cheap procedure of solving, or at least mitigating, the aboveindicated deficiencies of the prior art.

SUMMARY

The present inventors herein present a solution to the problems indicated in the background section above, the solution involving simulation of functionalities of a physical vehicle or parts thereof by means of testing of a virtual box vehicle. By virtualizing vehicle integration testing and simulating virtualized behaviours, individual vehicle components may be functionally tested at a very early stage during the vehicle’s design/manufacturing/testing process. The solution enables functional dependencies to be determined and possible fault discovery to be performed even before the physical components are designed. In addition, the solution allows possible functionalities or combinations of functionalities to be experimented with since there is no extra incurred costs associated with the virtual simulations. To this end, vehicle testers are provided with (at least theoretically) endless possibilities of combining and/or experimenting with various virtualized vehicle components and running customized simulations thereof.

Testing components of the virtual box vehicle provides numerous technical advantages in view of the prior art. The testing procedure may support use cases from rapid prototyping to continuous integration and testing of ECUs and associated software/hardware-in-the-loop testing (SIL/HIL). Hence, the solution enables validation, verification and quality assurance of ECUs and associated functionalities. Any signals associated with the vehicle may be virtually analysed and tested, including but not limited to signals transmitted through controller area networks (CAN), local interconnect networks (LIN), FlexRay, Ethernet, or WiFi, etc. Moreover, the solution supports services such as debugging and simulation environments, software and hardware agnostic collaboration platforms, and recording and/or replaying of signals and remote access.

In a first aspect of the proposed solution, a computer-implemented system for simulation of functionalities of a physical vehicle or parts thereof is provided. The system comprises a cloud-based computing resource being configured to: provide a virtual vehicle representation comprising a plurality of virtual vehicle components, each virtual vehicle component being associated with one or more control function representations of respective control functionalities of a physical vehicle component; process one or more user instructions, each user instruction being indicative of a removal, an addition, or a modification, of one or more virtual vehicle components included, or to be included, in the virtual vehicle representation; execute a test suite for virtual vehicle components included in the virtual vehicle representation; generate simulation data being indicative of control interactions, during execution of said test suite, between one or more control function representations associated with at least one of the virtual vehicle components and one or more control function representations associated with at least one other of the virtual vehicle components; and enable user access to said simulation data. In one or more embodiments, the cloud-based computing resource is further configured to, based on the simulation data, generate a specification of recommended physical vehicle components.

In one or more embodiments, the specification of recommended physical vehicle components includes electronic units required for a system or subsystem in a vehicle to be able to functionally operate in a physical vehicle setting.

In one or more embodiments, the test suite includes a plurality of vehicle test cases adapted to test said one or more control function representations.

In one or more embodiments, the cloud-based computing resource is configured to receive the test cases as user instructions.

In one or more embodiments, execution of the test suite reflects a default vehicle procedure.

In one or more embodiments, execution of the test suite reflects a particular vehicle driving scenario.

In one or more embodiments, the cloud-based computing resource is configured to repeat execution of the test suite after a processing of additional user instructions being indicative of a removal, an addition, or a modification of one or more virtual vehicle components included, or to be included, in the virtual vehicle representation.

In one or more embodiments, the system further comprising a virtual simulation and collaboration platform, said platform being software and hardware agnostic, said platform being configured to manage user interactions with the system, for instance said user instruction being indicative of a removal, an addition, or a modification, of one or more virtual vehicle components included, or to be included, in the virtual vehicle representation.

In one or more embodiments, said user access to the simulation data is configured to be enabled through the virtual simulation and collaboration platform.

In one or more embodiments, the virtual simulation and collaboration platform comprises: a client-side virtual design platform, a client-side physical design platform, and a server-side collaboration area. In one or more embodiments, said execution of the test suite comprises integration testing of the virtual vehicle representation, the generated simulation data comprising integration test data.

In one or more embodiments, the integration test data comprises test metrics for each tested virtual vehicle component in control interaction with other tested virtual vehicle components.

In one or more embodiments, the test metrics indicate an integration performance of one or more control function representations for each tested virtual vehicle component.

In one or more embodiments, said control functionalities of a physical vehicle component is adapted to control one or more vehicle actuators or vehicle sensory systems or subsystems.

In one or more embodiments, the cloud-based computing resource is further configured to retrieve the virtual vehicle representation from a virtual representation of a physical reference vehicle.

In one or more embodiments, said virtual vehicle representation of a physical reference vehicle comprises default components of a real vehicle to be tested and/or manufactured.

In one or more embodiments, said virtual vehicle representation of a physical reference vehicle is selected by means of one or more user instructions.

In one or more embodiments, the system further comprises a cloud-based storage resource configured to store said simulation data.

In one or more embodiments, the system further comprises a physical broker device, said physical broker device being configured to interface the cloud-based computing resource and one or more physical bus protocols of a physical box vehicle comprising a plurality of physical vehicle components.

In one or more embodiments, the physical broker device is configured to interface the one or more physical bus protocols of the physical box vehicle after one or more removals, additions or modifications of one or more physical vehicle components associated with the physical box vehicle. In a second aspect, a physical broker device is provided. The physical broker device is configured to interface the cloud-based computing resource of the computer- implemented system according to the first aspect or any of the embodiments thereof, and one or more physical bus protocols of a physical box vehicle comprising a plurality of physical vehicle components.

In one or more embodiments, the physical broker device is configured to interface the one or more physical bus protocols of the physical box vehicle after one or more one or more removals, additions or modifications of one or more physical vehicle components associated with the physical box vehicle.

In a third aspect, a computer-implemented method for simulation of functionalities of a physical vehicle or parts thereof is provided. The method comprises: providing a virtual vehicle representation comprising a plurality of virtual vehicle components, each virtual vehicle component being associated with one or more control function representations of respective control functionalities of a physical vehicle component; processing one or more user instructions, each user instruction being indicative of a removal, an addition, or a modification, of one or more vehicle components included, or to be included, in the virtual vehicle representation; executing a test suite for virtual vehicle components included in the virtual vehicle representation; generating simulation data being indicative of control interactions, during execution of said test suite, between one or more control function representations associated with at least one of the virtual vehicle components and one or more control function representations associated with at least one other of the virtual vehicle components; and enabling user access to said simulation data.

In a fourth aspect, a computer program product is provided. The computer program product comprises computer program code for performing the method according to the third aspect when the computer program code is executed by a processing device.

It should be emphasized that the term “comprises/comprising” when used in this specification is taken to specify the presence of stated features, integers, steps, or components, but does not preclude the presence or addition of one or more other features, integers, steps, components, or groups thereof. All terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the [element, device, component, means, step, etc]" are to be interpreted openly as referring to at least one instance of the element, device, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing will be apparent from the following more particular description of the example embodiments, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the example embodiments.

Fig. 1 is an embodiment of a computer-implemented system adapted to simulate functionalities of a physical vehicle or parts thereof, the embodiment including virtual vehicle components.

Fig. 2 is an embodiment of a computer-implemented system adapted to simulate functionalities of a physical vehicle or parts thereof, the embodiment including virtual and physical vehicle components.

Figs. 3a-b illustrate exemplary simulation data according to embodiments of the invention.

Figs. 4a-d is an embodiment of generating simulation data.

Fig. 5 is an embodiment of generating a specification of recommended physical vehicle components.

Fig. 6 is an exemplary detailed illustration of a computer-implemented system according to one embodiment.

Fig. 7 is a flowchart illustration of a computer-implemented method for simulation of functionalities of a physical vehicle or parts thereof according to one embodiment.

Fig. 8 is a computer-readable storage medium according to one embodiment. DETAILED DESCRIPTION OF EMBODIMENTS

Embodiments of the invention will now be described with reference to the accompanying drawings. The invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. The terminology used in the detailed description of the particular embodiments illustrated in the accompanying drawings is not intended to be limiting of the invention. In the drawings, like numbers refer to like elements.

Throughout the present detailed disclosure of the invention, distinctions will consistently be made between the physical (real) world and the virtual world. For a complete understanding of the disclosure, some clarifying terminology is first introduced.

The present invention generally enables physical vehicle components to be tested by virtual means in a virtual world. The virtual means is, for instance, a computer- implemented system or method, or alternatively a computer program product having program code for performing the method upon being executed by a processing device. Conversely, a physical world relates to actual physical vehicles and associated physical components. To this end, by providing a virtual vehicle representation of a physical vehicle, the physical vehicle components of the physical vehicle are represented as virtual vehicle components. In addition, it is understood that a physical vehicle component is associated with, or adapted to perform, one or more control functionalities in a physical vehicle setting. When the physical vehicle components are virtually represented in the virtual vehicle representation, they are associated with one or more corresponding control function representations . Each control function representation for each virtual vehicle representation is thus configured to be linked with and represent a behaviour of the corresponding physical control functionality.

By virtue of the virtual scheme as discussed in the present disclosure, the control functionalities of the physical vehicle components can be simulated, the simulated functionalities tested, and data resulting from the tested simulations further used to, for instance, assess one or more possible vehicle design modifications. The invention therefore serves as an adaptation to an intended technical use of data resulting from a simulation.

With reference to Fig. 1, an embodiment of a computer-implemented system 100 is visualized. The computer-implemented system 100 comprises a cloud-based computing resource 110, a cloud-based storage resource 120 and a client-side platform 130. Technical details and respective components of these computerized units will be further described with reference to Fig. 6.

The computer-implemented system 100 is adapted to simulate functionalities of a physical vehicle, or parts thereof, by providing a virtual vehicle representation 10. The virtual vehicle representation 10 represents a physical vehicle, without limitations to a particular type of vehicle. A physical vehicle may be any type of vehicle having ECUs that can be tested. To this end, a physical vehicle represented by the virtual vehicle representation 10 may be a car, a truck, semi-truck, trailer, motorcycle, electric bike, aerial vehicle, maritime vehicle or train, to name a few vehicle types. For reasons of brevity, the present disclosure refers to simulated cars, as can be seen in Fig. 1.

The cloud-based computing resource 110 is configured for providing the virtual vehicle representation 10. The virtual vehicle representation 10 is an example of the virtual box vehicle as discussed in the summary section of the present disclosure. The primary purpose of the virtual vehicle representation 10 is that it enables simulation of functionalities of physical vehicle components. Hence, the virtual vehicle representation 10 comprises a plurality of virtual vehicle components 20a-nn. It is therefore to be understood that testing of a virtual vehicle component 20a-nn indirectly refers to testing of a corresponding physical vehicle component, since the virtual vehicle component 20a-nn is a virtual representation of a physical vehicle component. More specifically, testing of a control function representation indirectly refers to testing of a corresponding physical control functionality, such as control functionalities being adapted to control one or more vehicle actuators (braking/steering/throttle control, etc.) or vehicle sensory systems or subsystems (e.g. electronic control of windshields, air condition, network(s), wipers, etc.).

The virtual vehicle components 20a-nn may represent any ECU of corresponding physical vehicle components. The virtual vehicle components 20a-nn shown in Fig. 1 are just exemplary components being associated with respective control function representations that can be tested. Any number of fewer or additional virtual vehicle components 20a-nn may be comprised in the virtual vehicle representation 10. In Fig. 1, the components 20a, 20b, 20c, 20aa, 20ag represent sensor devices (e.g. rear, side, front and back camera sensors), the components 20d, 20f, 20g, 20h, 20i, 201, 20o, 20p, 20q, 20r, 20z, 20ab, 20ad, 20ae represent various powertrain control modules (e.g. transmission control, engine control, vehicle body control, and so forth), the components 20e, 20j, 20n, 20s represent automatic braking modules, the components 20k, 20m represent environmental sensors (e.g. rain, humidity, temperature sensors), the component 20t represents a central vehicle computer, the component 20u represents an air control module, the component 20v represents vehicle networks, the component 20w represents a warning control module, the component 20x represents a vision camera system 20x (e.g. for providing inputs to the central vehicle computer to be processed for subsequent autonomous vehicle control), the component 20y represents a wiper control module, the component 20ac represents a control connector and the component 20af represents a battery module.

Virtual vehicle components 20a-nn included in the virtual vehicle representation 10 can be modified. Modifying a virtual vehicle component 20a-nn may involve adjusting one or more control function representations, for instance by inserting new data, removing existing data, setting operational constraint(s), introducing new control function representations and/or removing existing control function representations, to name a few exemplary modifications. Alternatively or additionally, vehicle components 20a-nn currently included in the virtual vehicle representation 10 can be removed. Yet alternatively or additionally, vehicle components 20a-nn not included in the virtual vehicle representation 10 can be added thereto. This provides dynamic control of which of the virtual vehicle components 20a-nn that should be subjects of a simulation, and to what extent. For instance, a software tester 132 may perform said dynamic control by providing one or more user instructions via the client-side platform 130. Hence, the cloud-based computing resource 110 is configured to process one or more user instructions 40 (see Fig. 4b) being indicative of a removal, an addition, or a modification, of one or more virtual vehicle components 20a-nn included, or to be included, in the virtual vehicle representation 10.

The cloud-based computing resource 110 is further configured to execute a test suite for virtual vehicle components 20a-nn included in the virtual vehicle representation 10. Accordingly, the virtual vehicle components 20a-nn are tested in relation to one another, i.e. what is commonly referred to as integration testing in the art of software testing. By performing integration testing of the various virtual vehicle components 20a-nn, their performances may be analyzed for determining how they operate together. The execution of the test suite is interpreted as running a simulation, where the simulation results in generated simulation data associated with the virtual vehicle representation 10, and hence the physical vehicle.

The execution of the test suite may reflect a default (real/physical) vehicle procedure (situation/behaviour/control maneuver). The default vehicle procedure may depend on various aspects such as, for instance, which physical vehicle the virtual vehicle representation 10 represents, what virtual vehicle components 20a-nn are included in the virtual vehicle representation 10 being tested, what control function representations are being tested, and so forth. Generally, however, it is realized that most vehicles of the same type share similar such procedures. For instance, the default vehicle procedure may be a default start-up procedure, a default shut-down procedure, a default right/left turn procedure, a default braking procedure, a default backing procedure, a default camera detection object procedure, a default lock-up procedure, a default acceleration procedure, a default automatic parking procedure, a default automatic driving procedure, a default lane- switching procedure, a default temperature control procedure, a default wiper control procedure, a default sensor control procedure, and so forth, including combinations thereof.

As a further detailed example, the default start-up procedure of a (real/physical) car having an electric motor typically involves the following steps: (i) putting the key into the ignition system, (ii) supplying electrical currents to the car by means of a battery system, (iii) converting electrical currents to be used for the motor starter, (iv) introducing fuel and spark into the engine cylinders, and (v) cranking the engine. Clearly, some variations may be realized for alternative default start-up procedures. However, the general principle applies. Other such steps may alternatively be realized for any of the other default vehicle procedures as described above.

Accordingly, the default vehicle procedures may be reflected in the execution of the test suite, e.g. as one or more conditional and/or assertive test conditions that are adapted to control the simulation of functionalities.

The execution of the test suite may reflect a particular vehicle driving scenario. For the same reasons as the default vehicle procedures, the particular vehicle driving scenario may depend on various aspects. However, some possible vehicle driving scenarios may include uneven road surface driving (e.g. due to various types of surfaces such as driving on gravel/snow/ice/etc.), weather scenarios (e.g. rain, snow, wind), operational restrictions (e.g. limited to a particular driving speed), to name a few scenarios.

The cloud-based computing resource 110 may be configured to repeat execution of the test suite after having processed additional user instructions being indicative of further modification(s), removal(s) or addition(s) of virtual vehicle component(s) 20a- nn. This provides additional flexibility in the generation of the simulation data.

During the execution of said test suite, the cloud-based computing resource 110 is further configured to generate simulation data being indicative of occurring control interactions between the control function representations of the virtual vehicle components 20a-nn. The execution of the test suite may thus comprise integration testing of the virtual vehicle representation 10, and the generated simulation data may thus comprise integration test data.

Once the test suite has finished executing and the simulation data has been generated, the cloud-based computing resource 110 enables user access to said simulation data, for instance through the client-side platform 130. By enabling user access to said simulation data, said user may further use the simulation data for assessing whether adjustments in the virtual vehicle representation 10 is necessary, for instance depending on various test metrics included in the simulation data. Some exemplary test metrics included in the integration test data are shown in Figs. 3a-b and will be explained later on in this disclosure. With reference to Fig. 2, an embodiment of a computer-implemented system 100 is visualized. The primary difference between the embodiment shown and explained with reference to Fig. 1 and the embodiment of Fig. 2 is that the system 100 of Fig. 2 comprises a combination of a virtual vehicle representation 10 (depicted in the “VIRTUAL WORLD”) and a physical box vehicle 160 (depicted in the “PHYSICAL WORLD”). The skilled person appreciates that the possible variations shown in Fig. 1 and explained with reference thereto are also applicable to the embodiment shown in Fig. 2. The additional variations of Fig. 2 will now be explained.

The physical box vehicle 160 comprises a plurality of physical vehicle components 162a-nn. The physical vehicle components 162a-nn may correspond to the physical versions of those components that was virtually represented in Fig. 1 (i.e. components 20t through 20ag), or a subset of them. An advantage of having the combination of the physical box vehicle 160 and the virtual vehicle representation 10 is that piecewise testing of the components 20a-nn, 162a-nn can be performed. In one example, some original equipment manufacturers (OEMs) whose business is to manufacture windshields may have the physical wiper control module 162e in a factory, and want to test the integration thereof with one or more additional components 162a-nn of a vehicle without having to blindly purchase a plurality of arbitrary components 162a-nn for making said testing available. The functionalities of these one or more additional components 162a-nn may hence be simulated in the virtual vehicle representation 10 and connected to the physical box vehicle 160. In another example, some OEMs may have a complete box vehicle readily available for subsequent assembling, but are missing one important component, e.g. the central vehicle computer 162a. The functionalities of the central vehicle computer 162a may hence be simulated in the virtual vehicle representation 10 and connected to the (almost complete) box vehicle to finalize the testing procedure. The skilled person will appreciate that the exemplary embodiment of Fig. 2 only illustrates one virtual world/physical world arrangement. Clearly, in other arrangements, the virtual vehicle components 20a-nn included in the virtual vehicle representation 10 and the physical vehicle components 162a-nn included in the physical box car 160 may depend on various aspects, such as the business of the OEM and thus the purpose of the simulation. The system 100 comprises a physical broker device 150. The physical broker device 150 is configured to interface the cloud-computing resource 110 and the physical box vehicle 160. More specifically, the physical broker device 150 is configured to interface the cloud-computing resource 110 and one or more physical bus protocols 161 of the physical box vehicle 160. In Fig. 2, four physical bus protocols 161 are shown, and they are connected to the central vehicle computer 162a. Alternatively, any number of physical bus protocols 161 being connected to any number of physical vehicle components 162a-nn may be realized.

Similar to the functionality of the cloud-based computing resource 110, the physical broker device 150 is configured to interface the one or more physical bus protocols 161 of the physical box vehicle 160 after one or more removals, additions or modifications of one or more physical vehicle components 162a-nn associated with the physical box vehicle 160. Hence, the combination of the virtual vehicle representation 10 and the physical box vehicle 160 including the physical broker device 150 enables the model being tested to customize both virtual as well as physical vehicle components 20a-nn, 162a-nn. Details of the physical broker device 150 will be further explained later on with reference to Fig. 6.

With reference to Figs. 3a-b, some exemplary simulation data 60 is shown. The skilled person will appreciate that any suitable simulation data 60 adhering to control functionalities of physical vehicle components can alternatively be generated. The simulation data 60 comprises integration test data including test metrics for tested virtual vehicle components being in control interaction with other tested virtual vehicle components. The test metrics may indicate an integration performance of one or more control function representations for each tested virtual vehicle component 20a-nn. The assumption is that these virtual vehicle components are associated with one or more control function representations of respective control functionalities of physical vehicle components. The integration performance of a control function may be a nominal value, or a percentage-based value, etc., in relation to a desired optimal performance.

For instance, the integration performance may indicate whether a control function is associated with a desired performance, whether the control function is malfunctioning, or whether the control function is operative at some arbitrarily reduced performance, e.g. 50%, 70%, 90% (or any other nominal value), of a desired maximal performance, in conjunction with the virtual vehicle components 20a-nn included in the simulation. The integration performance may be a moving average value during the execution of the simulation. The moving average value may be presented in combination with a desired threshold performance depending on various different aspects, such as integration interactions with one or more virtual vehicle components 20a-nn or groups of virtual vehicle components 20a-nn.

The simulation data 60 may be presented to the client-side platform 130 (cf. Fig. 1). The simulation data 60 may be shown in a graphical view 135 presented on e.g. a computer communicating with the client-side platform 130. The graphical view 135 may comprise a plurality of various control functionalities. For instance, the graphical view 135 may comprise a subscribe functionality 135a, a simulation-execute functionality 135b, a simulation-pause functionality 135c and a simulation-stop functionality 135d. The graphical view 135 is not limited to these particular functionalities 135a-d.

Fig. 3a shows simulation data 60 of wheel angles 62. The wheel angles 62 may include angles for a front left wheel 62a, a front right wheel 62b, a rear left wheel 62c, and a rear right wheel 62d. The wheel angles 62a-d are shown in diagrammatical illustrations where the respective x-axes denote simulation time (in this case the simulation shows the wheel angles 62 between approximately 640 and 656 seconds in the simulation), and the respective y-axes denote the number of wheel revolutions per minute during these simulation times.

Fig. 3b shows simulation data 60 of various motion parameters 64. The motion parameters 64 may include a vehicle speed 64a, a vertical acceleration 64b and a lateral acceleration 64c.

With reference to Figs. 4a-d, an exemplary embodiment of generating simulation data 60 of a virtual vehicle representation lOa-c is shown.

In Fig. 4a, the cloud-based computing resource 110 is adapted to provide a first virtual vehicle representation 10a. The virtual vehicle representation 10a may be stored in a cloud-based storage resource 120 and retrieved therefrom by a cloud-based computing resource 110. Alternatively, the virtual vehicle representation 10 may be provided via a client-side platform 130 operated by a user 132. The virtual vehicle representation 10a may be retrieved as a virtual representation of a physical reference vehicle. For instance, if the user 132 intends to perform integration testing of components of a particular vehicle manufacturer, the reference vehicle may comprise components corresponding to vehicles produced by said particular vehicle manufacturer. To this end, the reference car may comprise default components of a physical vehicle to be tested and/or manufactured. In the exemplary reference vehicle of Fig. 4a, six virtual vehicle components 20a, 20b, 20c, 20d, 20e, 20f are provided.

In Fig. 4b, the user 132 has sent a plurality of user instructions 40 to the cloudbased computing resource 110 through the client-side platform 130. The cloud-based computing resource 110 has accordingly processed these instructions 40, and provided an updated virtual vehicle representation 10b. As seen when comparing the first virtual vehicle representation 10a with the updated virtual vehicle representation 10b, the component 20b has been removed, the component 20d has been modified to include subcomponents 20da, 20db, and the component 20g has been added to the updated virtual vehicle representation 10b.

In Fig. 4c, the cloud-based computing resource 110 is executing a test suite 50 for the virtual vehicle components 20a-g included in the updated virtual vehicle representation 10b. The representation is thus assuming an executing state and is referred to as an executing virtual vehicle representation 10c. The execution of the test suite 50 may be instructed by the user 132 operating at the client-side platform 130. For instance, the execution of the test suite 50 may be triggered upon the user 132 activating the simulation-execute functionality 135b as discussed with reference to Figs. 3a-b. Alternatively, the cloud-based computing resource 110 may be configured to automatically run the execution of the test suite 50, for instance as controlled by some arbitrary timing intervals (each minute, hour, etc.), or as triggered by any of the modification(s), removal(s) and/or addition(s) being made by the user 132 to the virtual vehicle representation lOa-b.

The test suite 50 may be retrieved from the cloud-based storage resource 120, from the user 132 through the client-side platform 130, or a combination thereof. For instance, the cloud-based storage resource 120 may comprise a default test suite 50, which can then be complemented by user modifications.

The test suite 50 may comprise a plurality of test cases 52a-n, each test case 50a- n being adapted to test the control function representations of the virtual vehicle components 20a-g, and thus the control functionalities of the corresponding physical vehicle components. Test cases 52a-n may be developed by the user 132.

Fig. 4d illustrates ongoing execution of the test suite 50. The executing virtual vehicle representation 10c is configured to return simulation data 60, which may then be distributed directly to the client-side platform 130, or alternatively to the cloud-based storage resource 120.

Fig. 5 illustrates an embodiment of generating a specification 70 of recommended physical vehicle components. The specification 70 is based on the generated simulation data 60 from the executing virtual vehicle representation 10c shown in Figs. 4c-d. The specification 70 may include ECUs required for a system or subsystem in a vehicle to be able to functionally operate in a physical vehicle setting. The specification 70 may accordingly be used as a basis for ordering vehicle components from suppliers. The specification 70 may alternatively be used as a basis for modifying the test suite 50 or test cases 52a-n therein (cf. Fig. 4d). The specification 70 may alternatively be used for connecting the physical broker device 150 to other bus protocols 161 (cf Fig. 2). The skilled person will appreciate that there are other alternative uses for the specification 70 not explicitly accounted for herein.

With reference to Fig. 6, a computer-implemented system 100 is shown according to an exemplary embodiment. The system 100 may be any of the systems 100 as previously described herein. The system 100 comprises a cloud-based computing resource 110 (including a virtual vehicle representation 10), a cloud-based storage resource 120, a client-side platform 130, a virtual simulation and collaboration platform 140, a physical broker device 150 and a physical box vehicle 160. The skilled person appreciates that the exemplary system 100 is not limited to these particular units.

The cloud-based computing resource 110 may be hosted on a cloud-based server being implemented using any commonly known cloud-computing platform technologies, such as Amazon Web Services, Google Cloud Platform, Microsoft Azure, DigitalOcean, Oracle Cloud Infrastructure, IBM Bluemix or Alibaba Cloud. The cloudbased server may be included in a distributed cloud network that is widely and publically available, or alternatively limited to an enterprise. Alternatively, the server may in some embodiments be locally managed as e.g. a centralized server unit.

The cloud-based computing resource 110 may be in communicative operation with the cloud-based storage resource 120. The cloud-based storage resource 120 may be maintained by and/or configured as a cloud-based service, being included with or external to the cloud-based computing resource 110. Connection to cloud-based storage means may be established using DBaaS (Database-as-a-service). For instance, cloudbased storage means may be deployed as a SQL data model such as MySQL, PostgreSQL or Oracle RDBMS. Alternatively, deployments based on NoSQL data models such as MongoDB, Amazon DynamoDB, Hadoop or Apache Cassandra may be used. DBaaS technologies are typically included as a service in the associated cloudcomputing platform.

The cloud-based computing resource 110 may comprise a bi-directional streaming service 1102. The bi-directional streaming service 1102 may be based on any known remote procedure call technology known in the art, such as gRPC. As is well known, remote procedure call technologies apply protocol buffers (Protobuf) instead of JSON/XML message formats, thus typically including significantly smaller message sizes. The bi-directional streaming service 1102 may include an endpoint probe, where the client-side platform(s) 130 being in communication with the cloud-based computing resource 110 comprises another endpoint probe for enabling communication therebetween.

The cloud-based computing resource 110 may comprise a software container service 1104 adapted to deliver software containers to an operating system kernel of the system 100. Alternatively, the software container service 1104 may be complemented with or replaced by a virtual machine service. Software containers are capable of storing application data and related metadata that can run on any operative system. This in turn enables applications to be executed in various locations, e.g. on-premises, in public clouds or private clouds. The software container service 1104 may be based on any container service known in the art, such as Docker. The cloud-based computing resource 110 may comprise a software scaling service 1106. The software scaling service 1106 may be configured for automating deployment of the software container service 1104. The software scaling service 1106 may be based on any scaling technologies known in the art, such as Kubemetes.

The cloud-based computing resource 110 may comprise a code repository service 1108. The code repository service 1108, or at least parts thereof, may alternatively be stored in the cloud-based storage resource 120. The code repository service 1108 includes metadata associated with simulation files or otherwise test-related files. The code repository service 1108 may be based on any repository technologies known in the art, such as Git.

The virtual simulation and collaboration platform 140 comprises a client-side virtual design platform 1302, a client-side physical design platform 1304 and a serverside collaboration area 1110. Generally, the virtual simulation and collaboration platform 140 is adapted to manage all user interactions with the system 100, including user interactions between the client-side platform 130 and the cloud-based computing unit 110, as well as (collaborative) user interactions between instances of the client-side platform 130. To this end, it should be understood that the client-side platform 130 is not unique. The client-side platform 130 may involve a plurality of instances such that a plurality of persons operating respective instances of the client-side platform 130 may collaborate. Collaboration data may include any information that may be used for the simulation of functionalities of a physical vehicle or parts thereof, such as test-related files, simulation data, virtual vehicle representations, virtual vehicle components, and so forth. The collaboration data may be supplied from the cloud-based computing unit 110, for instance through the server-side collaboration area 1110.

Advantageously, the virtual simulation and collaboration platform 140 is both software and hardware agnostic (also known in the art as “device-agnosticism”). Accordingly, the advantages discussed in the summary section may be realized through the virtual simulation and collaboration platform 140 since any user may at any time write, read or subscribe to physical vehicle signals during production or testing of vehicles. The design platforms 1302, 1304 enable users of the system 100 to design test suites, adjust virtual vehicle representations, adjust physical box vehicles, and so forth. The design platforms 1302, 1304 thus function as excellent debug environments for experimenting with design ideas, cutting and assembling virtual/physical wires and setting up customized testing environments, to name a few advantages. This is indicated by the dashed arrows. While doing so, all (or some) information of the system 100 may be shared with other users through instances of the client-side platform 130 for incentivizing and encouraging collaboration in a device-agnostic manner.

As has been described with reference to Fig. 2, the physical broker device 150 is configured to interface the cloud-computing resource 110 and the physical box vehicle 160. The physical broker device 150 may comprise a broker device controller 1502, bus protocol ports 1504 and wireless communication interfaces 1506.

The bus protocol ports 1504 are adapted to be connected to the various physical bus protocols of the vehicle, as was discussed in conjunction with Fig. 2. Since different OEMs use different protocols and no one has yet to be set as standard, the physical broker device 150 is not limited to be connected to one particular type. For instance, the bus protocol ports 1504 may include connectors to physical bus protocols including but not limited to A ² B, AFDX, ARINC 429, Byteflights, CAN, D2B, Ethernet, FlexRay, IDB-1394, lEBus, I ² C, ISO 9141-1/-2, J1708, J1587, J1850, J1939, ISO 11783, KWP2000, LIN, MOST, Multifunction Vehicle Bus, SMARTwireX, SPI, VAN or UAVCAN. Moreover, the connection is not limited to any particular type of physical transmission media. For instance, the physical transmission media include fibre optic, single wire, twisted pair, IEEE 1394, MIL-STD-1553, MIL-STD-1773 or Power-line communication, to name a few.

The wireless communication interfaces 1506 may comprise any short-range or long-range wireless communication standards known in the art. For instance, the wireless communication interfaces 1506 may support technologies based on IEEE 802.11, IEEE 802.15, ZigBee, WirelessHART, WiFi, Bluetooth®, BLE, RFID, WLAN, MQTT loT, CoAP, DDS, NFC, AMQP, LoRaWAN, Z-Wave, Sigfox, Thread, EnOcean, mesh communication, or any other form of proximity -based device-to-device radio communication signal such as LTE Direct, W-CDMA/HSPA, GSM, UTRAN, LTE or Starlink. The broker device controller 1502 may be a microcomputer adapted to enable the functionality of the physical broker device 150. The microcomputer may include a processing unit being a general-purpose processor, an application specific processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a circuit containing processing components, a group of distributed processing components, a group of distributed computers configured for processing, or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The microcomputer may include one or more memories being non-volatile memories (e.g., read-only memories (ROM), erasable programmable read-only memories (EPROM), electrically erasable programmable readonly memories (EEPROM), etc.), and volatile memories (e.g., random-access memories (RAM)), or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a computer or other machine with a processor device. As an example, the functionality of the microcomputer may be implemented on a Raspberry Pi or other cheap and lightweight broker solutions.

Although not explicitly shown in Fig. 6, the system 100 may include a number of units known to the skilled person for implementing the functionalities as described in the present disclosure. The system 100 may comprise one or more computing units capable of including firmware, hardware, and/or executing software instructions to implement the functionality described herein. The system 100 may comprise one or more processor devices (may also be referred to as a control unit), memories and buses. The system may include at least one computing device having the processor device. The system bus provides an interface for system components including, but not limited to, the memory and the processor device. The processor device may include any number of hardware components for conducting data or signal processing or for executing computer code stored in memory. The processor device (e.g., control unit) may, for example, include a general-purpose processor, an application specific processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a circuit containing processing components, a group of distributed processing components, a group of distributed computers configured for processing, or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The processor device may further include computer executable code that controls operation of the programmable device.

The system bus may be any of several types of bus structures that may further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and/or a local bus using any of a variety of bus architectures. The memory may be one or more devices for storing data and/or computer code for completing or facilitating methods described herein. The memory may include database components, object code components, script components, or other types of information structure for supporting the various activities herein. Any distributed or local memory device may be utilized with the systems and methods of this description. The memory may be communicably connected to the processor device (e.g., via a circuit or any other wired, wireless, or network connection) and may include computer code for executing one or more processes described herein. The memory may include non-volatile memory (e.g., readonly memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.), and volatile memory (e.g., random-access memory (RAM)), or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a computer or other machine with a processor device. A basic input/output system (BIOS) may be stored in the non-volatile memory and can include the basic routines that help to transfer information between elements within the computer system.

With reference to Fig. 7, a computer-implemented method 200 for simulation of functionalities of a physical vehicle or parts thereof is shown. The method 200 is adapted to implement the functionality of the computer-implemented system 100 as has been described herein.

The method 200 comprises providing 210 a virtual vehicle representation 10 comprising a plurality of virtual vehicle components 20a-nn, each virtual vehicle component 20a-nn being associated with one or more control function representations of respective control functionalities of a physical vehicle component 162a-nn. The method 200 comprises processing 220 one or more user instructions 40, each user instruction being indicative of a removal, an additional, or a modification, or one or more vehicle components 20a-nn included, or to be included, in the virtual vehicle representation 10. The method 200 comprises executing 230 a test suite 50 for virtual vehicle components 20a-nn included in the virtual vehicle representation. The method 200 comprises generating 240 simulation data 60 being indicative of control interactions, during execution of said test suite 50, between one or more control function representations associated with at least one other of the virtual vehicle components 20a-nn. The method 200 finally comprises enabling 250 user access to the simulation data 60.

With reference to Fig. 8, a schematic illustration of a computer-readable medium 300 is shown according to one exemplary embodiment. The computer-readable medium 300 may be associated with or connected to the system 100 as described herein, and is capable of storing a computer program product 310. The computer-readable medium 300 in the disclosed embodiment is a memory stick, such as a Universal Serial Bus (USB) stick. The USB stick 300 comprises a housing 330 having an interface, such as a connector 340, and a memory chip 320. In the disclosed embodiment, the memory chip 320 is a flash memory, i.e. a non-volatile data storage that can be electrically erased and re-programmed. The memory chip 320 stores the computer program product 310 which is programmed with computer program code (instructions) that when loaded into a processing device, will perform a method, for instance the method 200 explained with reference to Fig. 7. The USB stick 300 is arranged to be connected to and read by a reading device for loading the instructions into the processing device. It should be noted that a computer-readable medium can also be other mediums such as compact discs, digital video discs, hard drives or other memory technologies commonly used. The computer program code (instructions) can also be downloaded from the computer- readable medium via a wireless interface to be loaded into the processing device.

The invention has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.