Vehicle software platform

Abstract

To provide a vehicle software platform configured to implement an abstraction model which supports future hardware addition for all vehicle types.SOLUTION: A vehicle software platform 20 is mounted on a vehicle 11, the vehicle software platform 20 being configured to download application software to be installed and configured to provide a variety of services to the application software. The services are divided into a plurality of domains based on a service-oriented architecture, the domains including at least: a driver domain 21 related to an occupant on the vehicle 11; a vehicle domain 22 related to the physical vehicle 11; and an environment domain 23 related to an environment surrounding the vehicle 11.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present disclosure relates to a vehicle software platform installed in a vehicle, and more particularly to a vehicle software platform for realizing a software-defined vehicle (SDV) in which vehicle functions are realized by software. [Background technology]

[0002] In recent years, technological innovation in the automotive industry has called for major changes in in-vehicle embedded systems. Conventional in-vehicle embedded systems are separated into domains (functional units of a vehicle) based on the vehicle's mechatronics, such as the powertrain, chassis, body, driving assistance, and cockpit. However, as computer software plays a larger role in autonomous driving and new technologies realize vehicle functions through software, it is necessary to control the entire vehicle in order to link each domain. This has led to a demand for in-vehicle embedded systems that unify each domain onto a single platform.

[0003] In addition, autonomous driving technology is diversifying the sensors used to understand the vehicle's surrounding environment, including LiDAR, cameras, radar, and millimeter-wave sensors, and new sensors are currently under development. Furthermore, the diversification of powertrains, including battery electric vehicles (BEVs) and hydrogen-powered electric vehicles (HEVs), in addition to existing internal combustion engines, is further diversifying hardware, including mechatronics. This is creating challenges such as ballooning software development costs, lengthening vehicle development times, and making it difficult to ensure sufficient quality. In response to these challenges, the concept of software-defined vehicles (SDVs) has attracted attention (see Non-Patent Document 1). Although SDVs are now one of the industry's top priorities, their definition and technical and commercial approaches remain unclear. [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] IT Media, Inc., "SDVs: The Shift from Cars to Mobility," [online], [Retrieved May 14, 2024], Internet <URL: https: / / atmarkit.itmedia.co.jp / ait / articles / 2401 / 15 / news004.html> [Non-patent document 2] Shunichi Doi, "TECHNOLOGICAL DEVELOPMENT OF DRIVING SUPPORT SYSTEMS BASED ON HUMAN BEHAVIORAL CHARACTERISTICS," IATSS Research, [online], [Retrieved May 14, 2024], Internet <URL: https: / / www.sciencedirect.com / science / article / pii / S0386111214601667?via%3Dihub> Summary of the Invention [Problem to be solved by the invention]

[0005] The inventor envisions an SDV as a vehicle or system that has the following characteristics: (1) The functions of the car are realized by software, and it is possible to change the car's functions and update and manage the software. (2) Software is abstracted and separated from hardware, making it possible to run the developed software on a variety of hardware. (3) (2) above is realized by a software platform with a common API that is independent of vehicle manufacturers and vehicle models.

[0006] (4) By using the common API described in (3) above, it is possible to develop applications without knowledge of the specific hardware of each vehicle or knowledge of functional safety required to ensure the safe operation of the vehicle.

[0007] (5) As a result of (4) above, not only traditional automotive software development companies but also providers of web services and the like can develop applications that run on the above platform.

[0008] By realizing such SDVs, it will be possible to add and update vehicle functions quickly. For example, if a vehicle can be released to the market without waiting for the software to be completed and the software can be installed later, it will be possible to bring the vehicle to market more quickly and easily add new functions. Furthermore, even if a defect occurs, the software can be updated quickly all at once, so cases that would previously have required a recall can now be resolved with just a software update.

[0009] However, in conventional automotive development, software development is dependent on the hardware domain (the functional unit of the vehicle). This makes it difficult to port the software to other vehicle models or hardware, and the software must be added or modified for each vehicle model or hardware (low portability). Under these circumstances, software updates and management are not easy, which has been an obstacle to the realization of SDV.

[0010] To solve the problems mentioned above and realize SDV, it is necessary to design a top-down API based on the modeling of the vehicle system, which is broadly defined as the higher-level system, rather than a bottom-up platform API design based on hardware abstraction that starts from the underlying hardware. This will make it possible to realize the five SDV characteristics mentioned above.

[0011] However, currently, hardware-based abstraction is the mainstream, top-down API design is not being carried out, and there is no clear modeling of vehicle systems to achieve this.

[0012] Furthermore, in traditional automotive development, development teams are divided by hardware, and there are barriers between engineers, such as differences in business units and levels of technical understanding, making it difficult to build a common model that would get all engineers thinking in the same way.

[0013] In view of the above-described circumstances, an object of the present disclosure is to provide a vehicle software platform capable of realizing an abstraction model that can withstand future hardware additions for all vehicle types. [Means for solving the problem]

[0014] A vehicle software platform according to one aspect of the present disclosure is a vehicle software platform installed in a vehicle, the vehicle software platform being configured to be able to download and install application software and to provide various services to the application software, the services being divided into multiple domains based on a service-oriented architecture, the multiple domains including at least a driver domain relating to vehicle occupants, a vehicle domain relating to the physical vehicle, and an environment domain relating to the environment surrounding the vehicle. [Effects of the Invention]

[0015] According to the present disclosure, various services are provided by the vehicle software platform. Therefore, application software only needs to use abstracted services provided by the vehicle software platform, and does not need to be directly aware of differences in hardware. This allows for hardware-independent application software, improving the portability of application software.

[0016] The services provided by the vehicle software platform are divided into multiple domains based on a service-oriented architecture: a Driver domain related to the vehicle's passengers, a Vehicle domain related to the physical vehicle, and an Environment domain related to the environment surrounding the vehicle.

[0017] These three domains are not based on conventional hardware, but are defined based on a service-oriented architecture. Specifically, services are classified from the three perspectives of human, vehicle, and environment. The idea that there are three elements that make up driving behavior—human, vehicle, and environment—is a relatively well-established concept, as described, for example, in Non-Patent Document 2. The vehicle software platform disclosed herein applies this concept as a software model, thereby providing an abstract model for all vehicle types that can withstand future hardware additions. This abstract model separates application software from hardware and can handle the entire world, including vehicles, other vehicles, traffic participants, road infrastructure, weather, drivers, remote systems, and more. In other words, rather than building a model starting from hardware as in the past, this approach shifts to building a model based on the three elements that make up driving behavior—human, vehicle, and environment—and thereby provides an abstract model that is completely separated from hardware.

[0018] Using such a hardware-independent model allows all vehicles to be equipped with the same platform, which significantly reduces software development costs, shortens development times, and makes it easier to update and add software. [Brief explanation of the drawings]

[0019] [Figure 1] FIG. 2 is a conceptual diagram showing the relationship between a vehicle and an external platform. [Figure 2]FIG. 1 is a conceptual diagram illustrating a configuration of a vehicle software platform. [Figure 3] FIG. 1 is a conceptual diagram illustrating an example of application software. [Figure 4] FIG. 1 is a conceptual diagram illustrating an example of a platform service. [Figure 5] FIG. 1A is an explanatory diagram showing an example of an API that provides a forward / reverse function, and FIG. 1B is an explanatory diagram showing the definition of an API related to specifying a destination position. [Figure 6] FIG. 1 is a flow diagram of an autonomous driving application. [Figure 7] FIG. 10 is a conceptual diagram showing the configuration of a vehicle software platform according to a first modified example. [Figure 8] FIG. 10 is a conceptual diagram showing the configuration of a vehicle software platform according to a second modification. DETAILED DESCRIPTION OF THE INVENTION

[0020] An embodiment of the present invention will be described with reference to the drawings. The vehicle software platform 20 according to this embodiment is realized by software installed in the vehicle 11. That is, the vehicle software platform 20 includes computer programs and data stored in a storage device provided in the vehicle 11. A computer built into the vehicle 11 reads these computer programs and data and executes processing to control the vehicle 11. In this embodiment, as shown in FIG. 1, the vehicle includes one central computer 12 and multiple control ECUs 13 connected to the central computer 12. The central computer 12 is a computer that controls the entire vehicle, and the vehicle software platform 20 according to this embodiment is executed on this central computer 12.

[0021] Additionally, control ECUs 13 are provided to control the hardware such as the brake system, steering system, and various sensors equipped on the vehicle 11. These control ECUs 13 control each function, for example, executing control that requires real-time performance. These control ECUs 13 can be controlled in a software manner by a vehicle software platform 20 executed on the central computer 12. This allows the central computer 12 (vehicle software platform 20) to control the entire vehicle in a unified manner.

[0022] As will be described in detail later, the characteristics of the control ECU 13 and the hardware are hidden by the vehicle software platform 20. Therefore, application software executed on the vehicle software platform 20 does not need to be aware of the characteristics of the control ECU 13 and the hardware.

[0023] As shown in FIG. 1, the vehicle software platform 20 can cooperate with an external platform 10 located outside the vehicle 11. The external platform 10 is, for example, a cloud server of a system provider or a development environment of a system developer, and is connected to the vehicle software platform 20 via the Internet. Software provided by the external platform 10 includes application software executed on the vehicle software platform 20 and system software included in the vehicle software platform 20. These pieces of software are downloaded to the vehicle 11 over the air (OTA) using a wireless communication function provided by the vehicle software platform 20. The application software downloaded to the vehicle 11 is installed in the vehicle software platform 20, allowing the vehicle 11 to use various services provided by the vehicle software platform 20.

[0024] 2 is a conceptual diagram showing the configuration of the vehicle software platform 20. As shown in this diagram, the vehicle software platform 20 is made up of a hardware layer including the central computer 12, an OS layer closest to the hardware layer, a foundation layer that runs on the OS layer, a service layer that wraps the foundation layer, and an application layer that runs using the service layer. As shown in Figure 2, the OS layer consists of a board support package, an operating system, and utilities such as common drivers and protocol stacks.

[0025] The board support package is a software library required to run the operating system on the hardware. This board support package absorbs the specifications of the central computer 12 and the hardware, allowing the operating system to allocate memory and use devices without worrying about the hardware specifications. This board support package includes, for example, hardware initialization processing, memory mapping processing, a boot loader, and device drivers (software for operating specific hardware).

[0026] As shown in Figure 2, the foundation layer includes a runtime. The runtime is a program that implements functions to control the vehicle 11 using functions of the OS layer. The implementation of this runtime changes depending on the physical configuration of the vehicle 11. For example, the number and location of doors on the vehicle 11 differ depending on the vehicle model, but this difference is absorbed by the runtime implementation. This allows the application layer, which will be described later, to control the doors without considering the differences in the number and location of the doors, or to obtain information on the number and location of the doors. Furthermore, the method of recognizing the surrounding situation differs depending on the type and performance of the sensors equipped on the vehicle 11, but this difference is absorbed by the runtime implementation. This allows the application layer, which will be described later, to obtain the results of identifying the surrounding situation without considering the differences in the type and performance of the sensors.

[0027] The OS layer and foundation layer described above are hardware-dependent software and are referred to as the "platform core." Because complex elements (such as differences in hardware, safety, and security) are encapsulated in this platform core, these elements do not need to be taken into consideration when designing application software that uses the platform core. This allows even software engineers who are not familiar with automobiles to develop application software.

[0028] As shown in Figure 2, the service layer is the layer that provides various services to application software. This service layer is composed of multiple platform services, each of which is implemented as a process that provides various APIs. As a result, this service layer provides a set of common APIs that are not dependent on hardware. In other words, this service layer hides differences in hardware, such as differences in vehicle models and equipment, and provides common, standardized APIs. When an API call is made from application software, the service layer passes this API call to the runtime, and the runtime program corresponding to that API is executed.

[0029] As shown in Figure 2, the application layer is a layer that includes application software. The application software is a user application that is provided according to the functions that the user desires to realize. The application software may be provided not only by the manufacturer of the vehicle 11 but also by a third party. This application software can access the functions of the vehicle 11 by using the API provided by the platform service.

[0030] Specific examples of application software are shown in Figure 3. As shown in Figure 3, possible applications include maintenance-related applications (e.g., applications that diagnose software vulnerabilities and applications that perform software updates), setting-related applications (e.g., applications that perform user settings to realize a driving environment tailored to the user's preferences), driving-related applications (e.g., applications for performing autonomous driving, applications for performing driving assistance, and applications for monitoring driving conditions), and user experience-related applications (e.g., applications for managing the status of the vehicle 11, such as whether the vehicle 11 is driving or being operated, and applications for managing the API status and application status). These application software are hardware-independent and can therefore be easily ported to different vehicle models and hardware that use the same platform services. However, the same behavior cannot be guaranteed when application software is ported to different hardware. This is because the range of services that can be provided is limited depending on the hardware. If an unsupported service (API) is called from a client (application software, etc.), the client is notified that the service is not supported.

[0031] (DVE model) Fig. 4 is a conceptual diagram showing platform services. As shown in Fig. 4, each service provided by the vehicle software platform 20 is divided into multiple domains based on a service-oriented architecture. Specifically, the services are divided into a driver domain 21 related to the passengers of the vehicle 11, a vehicle domain 22 related to the physical vehicle 11, an environment domain 23 related to the environment surrounding the vehicle 11, and a utility domain 24 that provides services that do not belong to any of these domains. In this embodiment, all services are categorized into these four domains.

[0032] In this system, a domain is a classification of services provided by the vehicle software platform 20 based on the characteristics of their components. This system does not classify services based on the functional units or hardware of the vehicle 11 as in the past, but rather classifies services from three perspectives: "human," "vehicle," and "environment." The inventors call this model the "DVE model," an acronym for "Driver," "Vehicle," and "Environment." Defining services under the constraints of this DVE model makes it possible to define services that are hardware-independent and use multiple hardware components across multiple platforms. This allows service users to build application software without being bound by hardware configurations.

[0033] Each domain is clearly separated by a predetermined unit constituting the software, such as an API, a class, a namespace, or a library. In this embodiment, a namespace is set for each domain. Furthermore, as shown in FIG. 5, the API for each service is provided as a method of a class (instance), and the domain to which the service belongs is determined by which domain (namespace) each class belongs to. Note that this method of defining domains is merely an example, and domains may be defined by other methods. For example, a library or class may be set for each domain, and the domain to which each service belongs may be determined by which library or class each service belongs to.

[0034] Furthermore, services included in a specific domain are provided only in that domain. Therefore, when application software uses a service, it calls the service by directly or indirectly specifying the specific domain. Note that services belonging to a specific domain can use services in other domains. For example, if application software calls a service in the driver domain 21, that service can internally use services in the vehicle domain 22 or the environment domain 23.

[0035] Each service provided by the vehicle software platform 20 is provided as an API common to all application software installed in the vehicle 11 and is available from the application software and other services. As already explained, the API according to this embodiment is defined as a method of a class. That is, a predetermined service is executed by calling a method on an instance of each class. These APIs are consistent across different hardware architectures and are hardware-independent, except that the level of functionality provided differs depending on the hardware performance.

[0036] (Driver Domain 21) The driver domain 21 relates to passengers of the vehicle 11, represented by the driver of the vehicle 11. Services included in this domain are composed of those that handle decision-making processing of actions performed by drivers in the real world (driving behavior, operation of equipment on the vehicle 11 other than driving, etc.), as well as the psychological state of the driver. The subject of this domain is decision-making processing in cognition, judgment, and steering in driving behavior, and recognition processing of the situation around the vehicle 11 is included in the environment domain 23, while recognition of the state of the vehicle 11 itself and steering processing are included in the vehicle domain 22. The main services included in the driver domain 21 include a behavioral model service and a psychological model service.

[0037] Behavioral model services are a group of services that provide functions related to human behavior, such as driver driving. These behavioral model services provide functions used in (semi-)automated driving, for example. These behavioral model services can also be used to predict driver behavior and monitor the driver's state.

[0038] This behavioral model service can use learned data obtained by machine learning of the driver's driving for autonomous driving control. Specifically, the system builds a behavioral model based on a rule-based approach and a data-driven machine learning approach by monitoring the driver's behavior (the behavioral model service is also used for this monitoring). This behavioral model is a hybrid model that combines the two approaches and is built for each driver. This behavioral model is used to determine driving behavior. When the behavior of the vehicle 11 is instructed using the behavioral model service, the driving behavior is determined using the machine-learned behavioral model, making it possible to reproduce driving that is natural for that driver.

[0039] As shown in Fig. 5(a), this behavioral model service includes an API that provides forward and backward movement functions for the vehicle 11. For example, the behavioral model service is made up of multiple classes such as Route, Run, and VelocityLimit.

[0040] The Route class has a Set method (ID=1) that sets the destination of the vehicle 11. When calling this API from application software, the method is specified in the format of "Driver::BehavioralModel::Route.Set()" as shown in Figure 5(b). Of these, the first "Driver" specifies the namespace corresponding to the domain, the next "BehavioralModel" specifies the namespace corresponding to the group of services within the domain, the next "Route" specifies the class corresponding to the functional unit, and the next "Set" specifies the method that identifies the API. In this way, by specifying the domain and making an API call, it is possible to use the services provided by the vehicle software platform 20. This is also true for other domains and services.

[0041] The Run class has a Set method (ID=2) that instructs the vehicle to start traveling and a Notify method (ID=3) that notifies the vehicle that it has reached its destination. When the Set method is called for an instance of the Run class, a behavioral model is used to generate parameters that reflect the characteristics of the driver stored in the learned data, and the parameters are used to call a service of the vehicle domain 22. This makes it possible to output a command to move the vehicle 11 forward or backward using parameters that reflect the characteristics of the driver.

[0042] The VelocityLimit class has a Set method (ID=4) that specifies the speed limit. The APIs described above are merely examples, and the class and method configurations can be freely configured. Also, various APIs other than those described here can be implemented.

[0043] A typical example of application software using this behavioral model service is an ADAS (Advanced Driver Assistance System). For example, when application software assists a human driver in driving, the behavioral model service receives environmental information about the vehicle 11 and real-time motion information about the vehicle 11 provided by services in the environment domain 23 and vehicle domain 22. Based on this input information, it calculates the output of the steering and accelerator (driving behavior) of the human driver. This output is used as a parameter when calling a service in the vehicle domain 22, which will be described later, and steering processing of the vehicle 11 is executed. In this way, driving assistance can be provided by the function of evaluating and predicting human driving behavior.

[0044] The psychological model service is a group of services that provide functions related to human psychological factors. That is, while the behavioral model service described above deals with human behavior, this psychological model service deals with psychology that may influence human behavior. This psychological model service can be used to dynamically adjust the behavior of the vehicle 11, such as the interior atmosphere and ride comfort, including music, temperature, and lighting.

[0045] A typical application of this psychological model service is an HMI that adjusts the in-vehicle environment according to the psychological state of the driver. By using this psychological model service, it is possible to realize application software that dynamically adjusts the dynamics of the vehicle 11, such as comfort mode or sport mode.

[0046] (Vehicle Domain 22) The vehicle domain 22 relates to the physical vehicle 11. Services belonging to this domain include those that handle the state management and control of the vehicle 11's equipment, such as the exterior and interior, the state management and control of the vehicle 11's motion, such as running, turning, and stopping, and the state management of other vehicle 11 specifications (specs, model, size, weight, etc.). The main services included in this vehicle domain 22 include a motion service, a cabin service, and an exterior service.

[0047] The motion service is a group of services that provide functions for reading or controlling the movement of the vehicle 11. This motion service can provide the current motion state of the vehicle 11, such as the moving speed of the vehicle 11, to application software or other services. The API that constitutes this motion service provides a read interface for acquiring various motion states of the vehicle 11 and a write interface for setting / controlling the state of the vehicle 11, such as steering and acceleration.

[0048] Cabin services are a group of services that provide functions for reading or controlling the status of elements within the vehicle 11. These cabin services provide functions related to all elements within the vehicle, such as seats, air conditioning, environment, music, and visual / auditory / tactile interfaces. By using the cabin services, the status of these elements within the vehicle can be obtained and, to the extent possible, controlled. For example, by using the cabin services, application software that adjusts the in-vehicle environment can be realized. That is, the application can use the behavioral model service and psychological model service to infer the driver's state and then use the cabin service to automatically adjust the vehicle interior to suit the driver.

[0049] The exterior services are a group of services that provide functions for reading or controlling the state of the exterior of the vehicle 11. The exterior services provide functions related to lights, wipers, and any other mechanisms that affect the exterior of the vehicle 11. By using the exterior services, for example, a sensor-driven intelligent wiper application can be realized.

[0050] (Environmental Domain 23) The environment domain 23 relates to the space outside the vehicle 11, i.e., the environment of the vehicle 11. Services belonging to this domain are made up of services that handle the recognition of roads and buildings and information about them, the recognition of moving objects such as other vehicles and pedestrians and information about them, and the recognition of climate such as temperature, humidity, atmosphere, and sunlight intensity and information about them. In many use cases, the environment handled by this domain refers to the short- to medium-range environment surrounding the vehicle 11, but it may also include very large spaces. Most of the services (APIs) that belong to this domain are read-only and only have a Read interface. The main services included in this environmental domain 23 include road environment services, transportation services, and surrounding environment services.

[0051] The road environment service is a group of services that provide functions for obtaining information on static objects such as roads and traffic lights. This road environment service provides a read interface for obtaining road infrastructure information. This road environment service also provides a read interface for obtaining information on any point (for example, a destination).

[0052] The traffic service is a group of services that provide functions for acquiring information on dynamic objects such as your own vehicle 11, other vehicles, pedestrians, etc. This traffic service provides a Read interface for acquiring dynamic traffic information.

[0053] The surrounding environment service is a group of services that provide functions for acquiring information about the physical environment of the vehicle 11, such as weather and temperature. The surrounding environment service provides a read interface for acquiring dynamic atmospheric information about the environment around the vehicle 11.

[0054] (Utility Domain 24) The utility domain 24 is a utility-type domain that does not belong to any of the above three domains. The main services included in this utility domain 24 include a system maintenance service and a communication service.

[0055] The system maintenance service is a group of services that provide functions related to the maintenance and upkeep of the vehicle 11, safety management of the in-vehicle system, etc. The system maintenance service includes services for updating the software that constitutes the vehicle software platform 20 and updating application software. The communication services are a group of services that provide the function of connecting to and communicating with entities outside the vehicle 11 (such as the external platform 10 or a cloud service).

[0056] (Example of application software implementation) As an example of application software implementation, we will explain using an autonomous driving application. Figure 6 shows a simple flow diagram of the autonomous driving application. This flow diagram simplifies the processing, and various processes not shown here are actually performed.

[0057] When performing autonomous driving using an autonomous driving application, first, the autonomous driving application calls a service (road environment service) of the environment domain 23 and requests map data of the destination, as shown in step 100 of Figure 6. After obtaining the map data of the destination from the service of the environment domain 23, the process proceeds to the next step 110.

[0058] In step 110, the autonomous driving application calls a service (transportation service) in the environment domain 23 to request the current location of the vehicle 11. After obtaining the current location of the vehicle 11 from the service in the environment domain 23, the process proceeds to step 120.

[0059] In step 120, the autonomous driving application calls a service (road environment service) of the environment domain 23 to obtain candidate driving routes from the current location to the destination. After obtaining candidate driving routes from the service of the environment domain 23, the process proceeds to the next step 130.

[0060] In step 130, the autonomous driving application calls a service (cabin service) in the vehicle domain 22 and displays candidate driving routes on the navigation screen. Once the driver (or a virtual driver) selects a route from the displayed candidates, the process proceeds to step 140.

[0061] In step 140, the autonomous driving application calls the service (behavioral model service) of the driver domain 21 and instructs the vehicle to start driving. Then, the process proceeds to the next step, step 150.

[0062] In step 150, the service (behavioral model service) of the driver domain 21 calls the service (motion service) of the vehicle domain 22 to start the vehicle 11. This starts the automatic driving.

[0063] In autonomous driving, the runtime of the behavioral model service can refer to the behavioral model and call the motion service with parameters according to the driver's characteristics. For example, the runtime of the behavioral model service receives the driver's steering, accelerator, brake, and other operations as input data, evaluates and predicts driving behavior based on this input data, creates parameters, and calls the motion service using these parameters. This allows autonomous driving to be performed according to the driver's characteristics. Note that the service (motion service) of the vehicle domain 22 monitors and controls the steering and acceleration / deceleration of the vehicle 11 until it arrives at its destination, and this information can be used by the runtime of the driver domain 21.

[0064] In parallel with the above, a service (road environment service or traffic service) in the environment domain 23 is called, and environmental information such as roads, traffic lights, and pedestrians is referenced. The environmental information acquired here is used by the behavioral model service to control steering and acceleration / deceleration. For example, control is performed such as stopping the vehicle 11 when the light is red, slowing down when the vehicle is getting close to another vehicle, and operating the steering wheel when the vehicle 11 is about to deviate from the road dividing line. In this case, too, the runtime of the behavioral model service can evaluate and predict driving behavior based on the environmental information to create parameters, and use these parameters to call the motion service. Once the vehicle 11 has reached its destination, the process proceeds to step 160 .

[0065] In step 160, the driver domain 21 service (behavioral model service) notifies the automated driving application that the vehicle has arrived at the destination. This completes the automated driving process.

[0066] In this way, by using the vehicle software platform 20 according to this embodiment, the services of each domain can be linked together, thereby realizing application software that is not dependent on hardware.

[0067] Furthermore, as described above, when controlling the driving of the vehicle 11, steering and acceleration / deceleration are not simply controlled based on the current vehicle state and physical parameters of the environment. Instead, the vehicle domain 22 service (motion service) is executed via the driver domain 21 service (behavioral model service). This configuration enables driving tailored to the driver's characteristics. It is well known that each driver has a different driving style, and even the same driver's driving style changes depending on the situation. Conventional systems have not been able to realize driving behavior tailored to the driver because they do not have a function to consider the driver's characteristics or monitor the driver's state. In this regard, the vehicle software platform 20 according to this embodiment utilizes not only the hardware services of the vehicle domain 22 and the environment domain 23 but also the driver domain 21 service, which provides the driver's current state, thereby enabling dynamic adaptation of driving behavior.

[0068] (Variation 1) In the above embodiment, one central computer 12 controls the entire vehicle 11, and the vehicle software platform 20 is executed on this central computer 12, but this is not limited to this, and multiple ECUs may share the responsibility of executing each service of the vehicle software platform 20.

[0069] 7 shows an example in which multiple ECUs share the execution of each service of the vehicle software platform 20. In this example, each service is shared and executed by three ECUs: an integrated control ECU 15, an ADAS-ECU 16, and a Cockpit-ECU 17. In this example, an instance of the vehicle software platform 20 is arranged in each of the multiple ECUs. In other words, multiple instances of the vehicle software platform 20 exist in one vehicle 11. However, each service entity (class instance or process) provided by the vehicle software platform 20 exists in only one ECU.

[0070] For example, since service S1 is a service executed by the integrated control ECU 15, its entity (class instance and process) exists in the integrated control ECU 15. Therefore, when application software (application A, application B) executed by the integrated control ECU 15 calls service S1, the processing is executed by the integrated control ECU 15.

[0071] On the other hand, the vehicle software platform 20 arranged in the other ECUs (ADAS-ECU 16 or Cockpit-ECU 17) provides only the proxy service S1_proxy. The proxy service S1_proxy has the same interface (API configuration) as the service S1 as seen from the application software, but does not have any physical entity. This proxy service S1_proxy is an interface that acts as a bridge to the service S1 executed in the integrated control ECU 15 and acts as a proxy for access to the service S1. Therefore, when application software (app C, app D, app E, app F) executed in the ADAS-ECU 16 or Cockpit-ECU 17 calls the service S1_proxy, the service S1 is called via the service S1_proxy, and the processing is executed in the integrated control ECU 15.

[0072] Furthermore, since service S2 is a service executed by the ADAS-ECU 16, its entity (class instance and process) exists in the ADAS-ECU 16. In addition, in the vehicle software platform 20 arranged in an ECU other than the ADAS-ECU 16 (the integrated control ECU 15 or the Cockpit-ECU 17), only the proxy service S2_proxy is provided. Therefore, when application software (app A, app B, app E, app F) executed by the integrated control ECU 15 or the Cockpit-ECU 17 calls service S2_proxy, service S2 is called via service S2_proxy, and the processing is executed by the ADAS-ECU 16.

[0073] Similarly, since service S3 is a service executed by Cockpit-ECU 17, its entity (class instance and process) exists in Cockpit-ECU 17. In addition, in the vehicle software platform 20 arranged in an ECU other than Cockpit-ECU 17 (integrated control ECU 15 or ADAS-ECU 16), only the proxy service S3_proxy is provided. Therefore, when application software (app A, app B, app C, app D) executed by the integrated control ECU 15 or the ADAS-ECU 16 calls service S3_proxy, service S3 is called via service S3_proxy, and the processing is executed by Cockpit-ECU 17.

[0074] In this way, multiple ECUs may share the execution of each service of the vehicle software platform 20. Even in this configuration, application software can use the vehicle software platform 20 without being aware of the configuration of the ECUs.

[0075] (Variation 2) The second modification is configured to execute a service in an ECU in which an instance of the vehicle software platform 20 does not exist.

[0076] 8 includes an integrated control ECU 15 in which an instance of the vehicle software platform 20 is arranged, and a Legacy-ECU 17 that does not have an instance of the vehicle software platform 20. The Legacy-ECU 17 is, for example, a small ECU that has been incorporated into the vehicle 11 before the vehicle software platform 20 was introduced. In order to use the Legacy-ECU 17 on the vehicle software platform 20, it is only necessary to implement a service interface for connecting to the vehicle software platform 20. This allows the Legacy-ECU 17 to execute the processing when a specific service is called.

[0077] In the example shown in FIG. 8, when application software (for example, application A or application B) calls service S3, it accesses a software component of Legacy-ECU 17 via the service interface, and processing is executed on Legacy-ECU 17.

[0078] In this way, by making it possible to access the Legacy-ECU 17 via the platform service, the functions of the Legacy-ECU 17 can be provided to application software executed on the vehicle software platform 20. In this case, the application software does not need to be aware of which ECU executes its processing, and therefore can use the vehicle software platform 20 regardless of the configuration of the ECU.

[0079] (summary) As described above, according to this embodiment, various services are provided by the vehicle software platform 20. Therefore, application software only needs to use abstracted services (APIs) provided by the vehicle software platform 20, and does not need to be directly aware of differences in hardware. This makes it possible to realize application software that is not dependent on hardware, improving the portability of the application software.

[0080] The services provided by the vehicle software platform 20 are divided into multiple domains based on a service-oriented architecture. Specifically, the vehicle software platform 20 includes a driver domain 21 related to the passengers in the vehicle 11, a vehicle domain 22 related to the physical vehicle 11, and an environment domain 23 related to the environment surrounding the vehicle 11.

[0081] These three domains are not domains based on conventional hardware, but domains defined based on a service-oriented architecture. Specifically, services are classified from three perspectives: humans, vehicles 11, and the environment. The idea that there are three elements that make up driving behavior—humans, vehicles 11, and the environment—is a relatively well-established concept. The vehicle software platform 20 according to the present disclosure applies this concept as a software model, thereby providing an abstract model for all vehicle types that can withstand future hardware additions. Using this abstract model, application software can be separated from hardware and can handle the entire world, including the vehicle 11, other vehicles, traffic participants, road infrastructure, weather, drivers, remote systems, and so on. In other words, rather than building a model starting from hardware as in the past, this approach shifts to building a model based on the three elements that make up driving behavior—humans, vehicles 11, and the environment—making it possible to provide an abstract model that is completely separated from hardware.

[0082] Using such a hardware-independent model makes it possible to equip all vehicles11 with the same platform, which significantly reduces software development costs, shortens development time, and makes it easier to update and add software.

[0083] That is, the vehicle software platform 20 according to this embodiment provides a common platform service that is independent of vehicle model and hardware, allowing anyone to develop application software using this platform service. Even engineers who are not familiar with vehicle structure or hardware can develop application software by focusing on their areas of expertise. Furthermore, the developed application software can be used on a variety of vehicle models and hardware, significantly reducing development costs and time. Furthermore, adding new functions or modifying existing functions to vehicles that have already been sold can be easily implemented without being aware of differences in vehicle model or hardware, since application software using the platform service can be added or updated via OTA or other means.

[0084] The present disclosure is not limited to the above-described embodiments, and various modifications are possible within the scope of the claims. For example, embodiments obtained by appropriately combining the technical means disclosed in different embodiments and modifications are also included in the technical scope of the present invention. [Explanation of symbols]

[0085] 10. External Platforms 11 vehicles 12 Central Computer 13 Control ECU 15 Integrated Control ECU 16 ADAS-ECU 17 Cockpit-ECU 18 Legacy-ECU 20 Vehicle Software Platform 21 Driver Domain 22 Vehicle Domain 23 Environmental Domain 24 Utility Domain

Claims

1. A vehicle software platform installed in a vehicle, The vehicle software platform is configured to be able to download and install application software and to provide various services to the application software; the services are divided into multiple domains based on a service-oriented architecture; The plurality of domains include at least a driver domain related to a vehicle occupant, a vehicle domain related to the physical vehicle, and an environment domain related to the environment surrounding the vehicle. Vehicle software platform.

2. The services provided by the driver domain include a behavioral model service related to the driver's driving; The behavioral model service can use learned data obtained by machine learning of a driver's driving for autonomous driving control. The vehicle software platform of claim 1 .

3. The behavioral model service includes an API that provides a forward / reverse function for a vehicle; When an API that provides the forward / reverse function is called, a parameter that reflects the driver's characteristics stored in the learned data is generated, and a service of the vehicle domain is called using the generated parameter, thereby outputting a command to move the vehicle forward or backward. The vehicle software platform of claim 2 .

4. The services provided by the vehicle domain include a motion service for reading or controlling the movement of a vehicle; The vehicle software platform of claim 1 .

5. The services provided by the vehicle domain include cabin services for reading or controlling the status of elements within a vehicle; The vehicle software platform of claim 1 .

6. The services provided by the vehicle domain include an exterior service for reading or controlling the state of the exterior of a vehicle; The vehicle software platform of claim 1 .

7. The services provided by the environment domain include a road environment service for obtaining information on static objects such as roads and traffic lights; The vehicle software platform of claim 1 .

8. The services provided by the environmental domain include a traffic service for obtaining information on dynamic objects such as other vehicles and pedestrians; The vehicle software platform of claim 1 .

9. The services provided by the environmental domain include a surrounding environment service for obtaining information about the vehicle's physical environment, such as weather and temperature. The vehicle software platform of claim 1 .

10. The services are provided as abstracted APIs that are not based on vehicle-specific hardware. The vehicle software platform of claim 1 .

11. The service is provided as a common API to all application software installed in the vehicle. The vehicle software platform of claim 10.

12. The plurality of domains further includes a utility domain that provides services that do not belong to any of the driver domain, the vehicle domain, and the environment domain. The vehicle software platform of claim 1 .

13. The services provided by the utility domain include a system maintenance service that enables software updates. The vehicle software platform of claim 12.

14. The services provided by the utility domain include a communication service for communicating with entities outside the vehicle. The vehicle software platform of claim 12.

Images