Car configuration module

A vehicle software management module with a central platform ensures efficient and secure software updates by performing updates in the background and managing communications, addressing the challenges of updating vehicle systems in operation or remote locations.

GB2702407APending Publication Date: 2026-06-10BARKER RYAN

Patent Information

Authority / Receiving Office
GB · GB
Patent Type
Applications
Current Assignee / Owner
BARKER RYAN
Filing Date
2024-11-01
Publication Date
2026-06-10

AI Technical Summary

Technical Problem

Existing vehicle computer systems face challenges in updating software efficiently, particularly when the vehicle is in operation or in remote locations with insufficient signal strength, leading to potential corruption and system failures.

Method used

A software management module installed in the vehicle's onboard computer system, capable of monitoring and updating software independently of vehicle operations, with modes for setup, maintenance, and customer use, and a central platform managing communications to ensure secure and efficient software updates.

Benefits of technology

Ensures timely and secure software updates with minimal downtime, reduces the risk of corruption, and enhances system reliability by performing updates in the background and managing communications through a central platform.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

A vehicle (e.g. car) software module 40 configured to be installed into a vehicle onboard computer system 50. Wherein the module can establish a communication link with a remote system 20 storing the
Need to check novelty before this filing date? Find Prior Art

Description

Background Many modern cars incorporate onboard computer systems to configure to control one or more systems within the vehicle. Over time, such systems are required to be updated, which requires the computer system to download new software. However, such downloads may result in the controlled systems being slowed, in other cases the vehicle may not be able to perform such updates when the vehicle is in operation or when there is insufficient signal strength for example when the vehicle is in a remote location. In the worst cases, the updates may be interrupted which could lead to the software becoming corrupted which can result in the computer systems failing. Therefore, there is a need to provide a means to monitor the vehicle’s computer system to ensure that the necessary updates have been performed. This system should be configured to correct the software, when necessary, more specifically, the provided system should be able to action an update to correct the software preferably independent from the vehicle’s other function such that the system may perform updates even when the vehicle is in operation. It is noted that the provided system will not only ensure that the vehicle computer systems are up to date with the correct software, but can also help reduce the time needed to perform such software updates. The provided system may also help with vehicle maintenance as the system will allow technicians or others working on the vehicle a means to easily check and manage the vehicle’s software when the vehicle is being serviced or repaired. Summary The claimed invention provides a software management module that can be incorporated into a vehicle, wherein the module is configured to monitor the software installed into the vehicle systems. The claimed invention may be in the form of a computer chip that can be installed into the vehicle’s onboard computer system, or as a separate module unit that could be installed onboard the vehicle and is then connected to the vehicle computer system such that information can be transferred between the computer system and the module. The claimed invention may be installed in a location proximate to any information ports in the vehicle computer, such as an OBD port that the claimed invention may be connected to, alternatively, the claimed system may be installed proximate to or within the Central Electronic Module of the vehicle. In general, the claimed module provides an apparatus that is capable of downloading and installing software and software updates that are to be implemented into the vehicle's computer systems. Such a module can help reduce the time required to install such software in the vehicle as the module can perform the download in the background, even when the vehicle is in operation. It is noted that, in such cases, the system may download and store the software update such that it can be installed and implemented the next time the vehicle is not being operated. This will help save time both by ensuring the software updates are made available as soon as possible and also save the user time by ensuring there is no downtime. In this case, downtime refers to a time wherein the vehicle cannot be operated as the system waits for the software to download. The module may also be to perform software checks. More specifically, the module may be configured to analyse the downloaded software to ensure there are no corruption errors during the download. If such an error occurs the system may be configured to reinitiate the download to replace the software with a non-corrupted version. The module may also be configured to determine when there are any available updates for the vehicle’s computer system. In some cases, the module will be configured to receive a notification provided by the software manufacturer that indicates when an update is available. On receiving the notification, the module will initiate the software update download immediately or the next time the system is activated. In some cases, the system may be configured to perform automated update checks wherein the module periodically checks for available updates. In some cases, the module may be configured to perform the update checks after a predetermined time has elapsed. The problem with such systems is that they require the module to be constantly active to perform checks for updates or notifications. Therefore, in some cases, the system may be configured to perform the update check when the system is initiated and before shutting down or going into standby. This way the system does not need to perform continuous checks for updates, this can help save power. However, it is noted that the updates can be ready at any time therefore it may be preferable for the system to perform some periodic checks when the vehicle is in operation or at the user’s demand to ensure there is no risk of the system missing an update. This also reduces the system downtime as the system can ensure that the update is ready as soon as possible. To achieve the above-mentioned effect the claimed module will comprise a transmitter and receiver configured to communicate with a remote system that provides the necessary software for the vehicle including the initial configuration data and any updates to said software. As the system would be configured to be used with different makes and models of vehicles the module would be configured to establish a communication pathway with many systems before filtering down to the desired system from the vehicle manufacturer. More specifically, during the module’s installation the user may input the vehicle's make to ensure that the module only establishes communication with the vehicle manufacturer. The user may further input the model of the vehicle to ensure the system establishes communication with the specific system that handles the software for that model. This can help limit the amount of communication links the system needs to form which can reduce the amount of processing power needed to operate the module. Additionally using this method to ensure that there is only one communication link between the module and the vehicle’s manufacturer can help improve the security of the device as the formation of fewer communication channels reduces the risk of said communications being hijacked by a malicious system. In the preferred embodiment of the system, the module would be configured to have a plurality of modes, each mode providing different functionality depending on the vehicle location and status. More specifically, the system may comprise three modes setup mode, maintenance mode and customer mode. Wherein the first mode will be used during the initial setup of the system, which will preferably be when the vehicle is first manufactured but may also be used when the module is retrofitted into an existing vehicle. In this mode, the user can input the make and model of the vehicle and set up communication with the vehicle's manufacturer. This link allows the system to download the essential software required to interface with the vehicle's computer systems and to install the initial software and future updates. Once this initial download is complete the system may be locked out of this mode to avoid the later users accidentally tampering with the systems settings. The second mode will be used when vehicle maintenance is being performed, for example during a vehicle M.O.T or service. In this mode, the user can analyse the vehicle's systems. Testing the vehicle's computer system and ensure that the most recent updates are installed and functioning correctly. This way the module can help to reduce the time needed to perform vehicle maintenance on the vehicle’s computer systems. It is noted that this mode may also be used when the vehicle is being repaired, for example after the vehicle has been in a collision to perform a rapid analysis of the vehicle's systems and repair any software data that had been damaged, using the established link from the first mode. The third mode of the module would be passive, referred to as the customer mode as this would be the mode used after the vehicle has been purchased and is being used by the customer. This mode is passive meaning it blocks access to the module's settings preventing the customer from tampering with the settings of the module or using the module to alter the vehicle’s computer systems. This mode’s function is simply to monitor the vehicle's software and install updates when necessary. As discussed above this may be performed passively as a background function allowing the data for the software updates to be downloaded even when the vehicle is in operation, so long as a signal is available to receive the necessary data through the established communication link setup in the first mode. With these modes, it is noted that the module will always initiate in the first mode until setup is complete, once complete it will move to the second mode to receive any available updates and run an initial diagnostic analysis of its software and the vehicle computer system, after which the module will be set to the customer mode. However, the module will also possess the capability to be manually swapped between modes. This will not be a function of the module alone to prevent the customer from changing modes. Instead, the modules will be paired with a maintenance device which will be used by the vehicle manufacturer and / or mechanical technicians that perform maintenance on the vehicle. This aired device will be configured to be coupled to the module via a wired or wireless connection, and once coupled will allow the user of the device to change the module’s mode and control the module's settings and functions for the chosen mode. This will allow those using the paired device to recalibrate the module and perforce the necessary updates and repairs during maintenance. The device may also be used to change the module's initial settings which can be used to re-establish a communication link with the manufacturer for example, when the vehicle has been damaged or when the manufacturer changes their servers so that the software updates are at a different location. The initial setting may also need to be changed if the module is installed into a different vehicle for example when a manufacturer recycles the module or when the customer wishes to move the module over to a new vehicle. It is noted that the module may include additional modes that are configured to work with the modes described above. In particular, the module may comprise installation modes which are used when one of the other modes initiates the installation of a software update. This mode may be configured to limit the vehicle's computer system actions while the update is being installed. This can prevent the user from interrupting the software installation, as such interruptions may result in the software update being corrupted. The system may also comprise a recovery mode which stops the computer system when faulty or corrupted software is detected, this mode will then initiate a download of the correct software version to correct the error, this may be the current version of the software if the download was corrupted, or the previous version if the current update is faulty. Both of these modes prevent the customer from using the computer system or at least a part of the computer system such that the operations of the system do not interrupt the software update. These modes for example may prevent the computer system from starting when the vehicle is initially activated until the software update is completely installed. In some cases, the invention may further comprise a platform which is in communication with both the claimed module and the manufacturer systems. This platform is configured to manage the communications between the module and the manufacturer servers acting as a mediator for the communication. This way the communication links between the modules and the manufacturer servers, this way the platform can monitor and verify the communication between the modules and the server to ensure that there are no malicious communication or false communication links, thereby increasing the security of the communication. The platform may additionally be configured to manage the software downloads. More specifically, the car manufacturers may establish links between their software servers and the platform to upload the updated software to the platform. On the platform, the various software updates can be stored in a database, which further contains information indicating which makes and models of cars require each of the stored software updates. This way the modules can retrieve the software updates directly from the platform instead of the manufacturer servers. This will prevent the need for the modules to communicate with the manufacturer's servers helping to improve the security of the system as the modules cannot be used to directly access the manufacturer’s servers. Also, as all communication would need to go through the platform there is a reduced risk of malicious communications. It is also noted that the platform can be configured to receive notifications from the manufacturers to indicate when there is a new software or software update to be installed within the database of the platform. On receiving the indication, the platform can initiate a download to receive the updated software for storage. The platform may also be configured to send an alert notification to the modules that require this new software. This notification can help initiate the module download of the new or updated software as described above. Further, the platform may store a record of each software stored within the database with an identification number that can indicate the version of the software, such that each update to a specific software changes the software number. It is noted that the module will download a copy of the ID when they download software or an update from the platform, this ID can then be stored within the module such that the user of the paired device can see the ID of at least the most rec. Using these ID numbers the user of the paired device performing maintenance on the vehicle can quickly identify if the software installed by the module is up to date by comparing the ID of the installed data to the ID in the platform database. The ID may also comprise elements that allow the comparison of the software ID to be performed more easily. For example, the ID number may include a version number or a date that indicates the day the software update was uploaded to the platform. This will allow the user of the paired device to identify if the software is up to date, if it is not the user may use the paired device to initiate the software update in the module. Further, the ID may be used by the manufacturers to ensure that the software version on the platform is up to date with the software they have released, if not the manufacturers can initiate an upload of the latest software update to the platform. By using the above-mentioned platform, the claimed system provides a centralised server wherein the software from multiple manufacturers can be stored and accessed with ease. The platform also helps improve security as the manufacturers can provide access to the software without leaving their servers vulnerable, as the module users will not have direct access to the manufacturer’s servers. This protects the manufacturer’s systems from potential threats that may be caused by allowing access to their system servers. As a further security measure, each vehicle may have its own ID, such as a vehicle VIN, that can be used to couple a vehicle to a specific module. This ID may include elements that help identify the vehicle such as letters indicating the make and / or model of the vehicle, or part of the vehicle's licence plate. This way the manufacturers can keep track of each module that has been installed into their vehicles and can create a list indicating which vehicles / modules require each of the software produced by the manufacturer. This record can be provided to the platform to help detect and track illegitimate downloads of the manufacturers' software. And can be used during maintenance to ensure the module contains the right type of software for the vehicle's make and model. The platform may also comprise a list of paired devices, wherein each device has its own ID and password to ensure that a user does not have access to the software stored on the platform without an authorised device. This further improves the system security ensuring that there is limited access to the available software data. This ensures that only authorised personnel may access the platform data. The system may also require the paired device to log into the platform before it can access the module systems. This means the user of the device needs to be authorised using the device-specific password before it can alter the data on the module or change the module modes. As previously noted, the paired device needs to be coupled to the module during use. To improve security, it is preferable for the device to be configured to be manually coupled to the module, for example through a cable that needs to be inserted into a corresponding port in the module. This way the system ensures that there are no wireless communications that may be maliciously hijacked, as the device must be physically attached to a module before the latter can communicate with the platform. This can help prevent the amount of malicious communication between the paired device and the module or platform. By using this system, the manufacturer is provided with a secure means to automate the vehicle software update process, while keeping their vehicle software secure via the platform. In addition, the module provides a means of installing the software quickly with minimal effect on the vehicle performance due to the reduced downtime. Further, the paired device provides a means to quickly monitor and diagnose any software issues that may occur using the modules functionally to quickly repair the issue by re-installing the required software update or reverting to a previous version of the software when necessary. Detailed Description The claimed invention is depicted in the following figures: Figure 1 - depicts a schematic depicting the elements of the vehicle software management system. Figure 2 - depicts a block diagram depicting the general function of the claimed vehicle software module. Figure 3 - depicts a block diagram indicating the steps to set up the claimed module. Figure 4 - depicts a block diagram indicating the step of using the maintenance mode of the claimed module. The figures comprise the following features: 10 - Vehicle software management system 20 - Manufacturer server 30 - Internet platform 40 - vehicle software module 50 - control device 100 - notification step 110- download step 120 - disruption checking step 130 - installation step 200 - initiate the first mode step 210 - initial download step 220 - software checks step 230 - initiate the third mode step 300 - controller connection step 310 - initiate the second mode step 320 - module check step 330 - software check step 340 - software correction step 350 - initiate the third mode step The claimed invention provides a module configured to be incorporated into a vehicle. This module may be in the form of a computer chip installed into the vehicle’s onboard computer system, or as a separate module contained within a housing that can be installed into the vehicle and coupled to the vehicle's computer system, such that the module can communicate with the computer system to exchange data. The module forms parts of a larger system configured to manage the software present on the vehicle’s computer system. In particular, the module is configured to initiate downloads of software and future software updates for the vehicle’s computer system allowing the data for the software to be received by the module as a background function. That is to say, the downloading of the software does not disrupt the vehicle operation as the module handles the download independently of the computer system. The software can then be installed onto the computer system during a time wherein it will not disrupt the vehicle operation such as when the vehicle is initially starting up or when it has been switched off. This way the module helps to reduce the downtime needed to install computer software updates. Figure 1 depicts the further elements of the preferred embodiment of the vehicle software management system 10. The system 10 comprises several remote servers 20. The servers 20 would belong to the various vehicle manufacturers or companies that produce the software to be used in the vehicles utilising the claimed module. For improved security, these servers 20 would be in communication with a centralised platform which will manage the distribution of software to the modules. From the platform 30 the modules can receive the software without needing to communicate with the manufacturer servers directly, thereby reducing the risk of cyber threats to the manufacturer and company systems. The platform 30 comprises a plurality of communication channels that couple to the plurality of modules 40 that will be installed into various vehicles. The platform is configured to store data identifying each of the modules 40 and the vehicles they are installed into such that the platform can pair each module 40 with the appropriate software that they require. This way the communications between the platform 30 and module 40 can be more direct reducing the number of unnecessary communications as the platform would only send software update notifications to the specific modules that required that software. It is noted that each module 40 would have a communication link with the platform 30 through suitable communication protocols to allow the module 30 to receive both notifications of a software update becoming available and to receive the software data from the platform. The software notifications may be sent from the manufacturers to the modules directly or may be relayed through the platform 30. However, it is preferable for the platform 30 to produce the notifications whenever the stored software is updated as the platform will have records of the specific modules 40 that need to be notified and this method removes the need for direct communication links between the modules 40 and the manufacturer and company systems thereby reducing the risk of security risks to these companies. In the system 10, the modules 40 would be configured to automatically detect the software update notification which indicates that new necessary software is available, on receiving the notification the modules 40 will initiate the download of the software as a background process. This means that the module 40 itself performs the download to not affect the processes of the vehicle’s computer system, allowing the download to occur without affecting the operation of the vehicle allowing the download to occur even when the vehicle is being used. Once the updated software is downloaded it can be stored within the module 40 and then installed into the vehicle computer system at a later time, when it will not disrupt the vehicle operations, such as when the vehicle is initially started or when it is standing idol. The module may also perform an analysis of the downloaded software data. This analysis can detect when the downloaded data is corrupted, for example when the data is incomplete due to download interruption or other errors. On detecting such a defect, the module 40 may initiate a further download to replace the faulty software data. In some cases, the module may also be configured to test the downloaded data’s compatibility with the vehicle's computer system. This compatibility check may include sending test signals to each of the components in the vehicle that the computer system is configured to control and / or communicate with, thereby ensuring that each of the components that the software is configured to control and / or communicate with are present and working before installing the update. This can ensure that the hardware is compatible with the software being downloaded or installed before the update is performed. If the data is not compatible the module 40 would be configured not to install the new data. In these cases, the module 40 may also download the previous version of the software such that the stored data is the last compatible update. The module 40 may also be configured to send an error message to the platform 30 or the company system 20 to indicate the faults in the software so that the software update can be corrected. It is noted that if such incompatible data was installed it may result in the computer system sending error messages to the user as the system attempts to communicate with components that are not present in the vehicle. It is noted that such test signals may also be used when the vehicle is being repaired or when the system is in maintenance mode to check that all the communication channels between the vehicle computer system and the different components of the vehicle are functioning. If the channel is not functioning the modules 40 may provide an alert indicating an error highlighting the component that did not respond as this may indicate that the connection to the computer system is damaged or the component is damaged or missing. This can help indicate to the user a problem in the vehicle’s system that will need to be addressed and may otherwise have gone undiagnosed. The figure also depicts a mobile control device 50 that is configured to be used with the module 40. In particular, the module is configured to perform the software updates described above automatically, which means without the need for user input. The mobile control device 50 can be used by authorised personnel to provide inputs to the module 40. These inputs can include changing the system settings of the module 40 or using commands to initiate a data analysis, software update download or software installation. This way the control device 50 can assume direct control of the module 40. The control device may also be used to alter the settings of the module 40 such as resetting the module or changing the vehicle make or model the module is configured for. In addition, during vehicle maintenance, the control device 50, may use the module to test the vehicle computer system and the downloaded software for faults and may be used to perform repairs to the software by downloading and installing the same or different versions of the necessary vehicle software. It is noted that the control device 50 would preferably require a physical connection to the module 40 that it is controlling. For example, the control device may comprise a cable that needs to be connected to a port in the module, such as an OBD port. This way each control device can only control a single module 40 at once. This also ensures that there are no wireless communications that could be at risk of being hacked. In some cases, the control device 50 may be required to provide a password to ensure the user is authorised. This password may be user-specific or module-specific, in the latter case, the password may be printed on the module housing. By using these elements together, the invention provides a system that allows for vehicle software to be downloaded and installed into a vehicle without disrupting the operation of the vehicle, thereby reducing downtime required when updating the vehicle software. Further, the system can perform software analysis to correct any errors within the vehicle software, thereby making the software update process more reliable, and reducing the risk of the vehicle being out of action due to faults in the software. Lastly, the design of the system reduces the risk of cybersecurity threats by having the communications between the customer end modules 40 and company end servers 20 be managed by the online platform removing the need for direct communication between the end systems and allowing the communications to be monitored by a central system. Figure 2 provides a block diagram depicting the basic functions of the module 40 once installed in the vehicle. As previously noted, the process begins at step 100 with the module receiving a notification indicating that a software update is available, from either the platform 30 or a manufacturer’s company server 20. The notification will trigger step 110 wherein the module 40 downloads the updated software from the platform 30. It is noted that the module may be configured to constantly scan for the notification, receiving the notification as a message, like an SMS or email, in other cases, the module may be configured to periodically scan for the update notification to minimise the amount of energy and processing power being used to scan for the update, thereby improving the efficiency of the module 40. Once the module 40 has downloaded the software update the module 40 may perform checks to ensure that the data is complete, and not corrupted if not then the module may perform another download. If the data is complete, it can be stored ready to install. At step 120, the module 40 is configured to perform a further check on the status of the vehicle’s computer system. These checks are configured to see if the stored software can be installed without causing disruptions to the vehicle. For example, the check will prevent the system from installing the software when the vehicle is in operation, for example when it is moving, as this may cause the computer system to stop working temporarily which may be hazardous to the vehicle. Therefore, the check will determine if the vehicle is in a status where the software can be installed safely such as when the vehicle is initially started, is being switched off or when the vehicle is idol. When this check has been passed the system moves on to step 130 where the stored software is installed on the vehicle computer system ready to be used. In some cases, the module 40 may be configured to have various modes, with each mode providing different functionality depending on the status of the vehicle. Figured 3 and 4 provide block diagrams depicting how these different modes may be used. Figure 3 provides a block diagram showing the process used to initially set up the module 40 once it has been installed into a vehicle. In step 200 the module 40 is set to a first mode, referred to herein as the setup mode. This mode may be used when the vehicle is being manufactured or when the module 40 has been retrofitted into a vehicle. In this mode, the initial settings of the module 40 can be configured as the module 40 will be in factory settings at this point. The set-up mode will allow the user to input the necessary details for the module to function, such as the type of vehicle and / or computer system the module is installed into. This data may then be stored as part of a module ID that may be used by the platform to pair the module to the correct software. After the initial settings have been stored in the module 40, the system moves to step 310. In this step, the module downloads the software required by the vehicle’s computer system. This step may include sending a signal to the platform 30 or servers 20 to request the software. This request may include data indicating the type of vehicle or computer system the module is attached to, or a module ID that uses elements indicating this information. On receiving the request, the module 40 will receive and install the necessary software. At this stage, the platform 30 may use the information from the request or the communication between the module 40 and the server 20 to pair the module to the correct software. The platform 30 stores the pairing in a database, this way the platform can identify which modules need software updates, each time the software stored in the platform 30 is updated. In step 220, the module can perform software checks on the downloaded software. As previously mentioned, these checks can be used to ensure the software is complete and that it is compatible with the vehicle computer system. If the data is corrupted or incomplete the module 40 will initiate another download. If the software is incompatible the system may send an error message to the platform 30 or server 20. Once the software check is complete the software can be installed onto the vehicle computer systems. Once this step is complete the system can move to step 230, wherein the module changes to a different mode. In this case, the module 40 changed to the customer mode. In a customer mode, the settings of the module 40 become locked stopping the person who buys the vehicle from changing any of the settings. In the customer mode, the module will only perform the automated software updating process as described above. Figure 4 depicts a block diagram of a further process used when the vehicle and / or module 40 undergoes maintenance and repairs. In this process, a control device 50 can be used to perform diagnostics and software repairs on the module 40. More specifically, in step 300 the user of the control device will couple the device 50 to the module 40 inside the vehicle, this usually involves connecting a cable to a port in the module housing. Once connected the user may be required to input a password or other code to verify their authority and to establish a communication link with the module 40. Once the connection is established the user may use the control device 50 to control the module 40. In step 310, the control device 50 is used to change the module 40 from its current mode into a maintenance or repair mode. In this mode, some of the module’s settings are unlocked allowing the device 50 to assume control of the module 40 initiating different commands to the module 40 to perform diagnostic scans or other processes. At step 320, the module 40 sends module data to the control device 50, this data can then be displayed to the user and contains details about the module, such as module ID, current settings, the current software stored in the module 40 and a list of previous actions such as the last time a software update was installed. This data can be used to form an initial check to see if the module is functioning correctly. It is also noted that the control device 50 may receive information from the platform such as a list of software updates for the software paired with the module 40 which may indicate if the module has failed to download the most recent update. It is noted that in some cases the module 40 and platform 30 may provide a software ID for the software stored in the module 40 and paired with the module 40 on the platform. This software ID may include elements indicating a version number or a date that the software was made available to allow the user to compare the software in the module 40 to the most recent software update more easily. In step 330, the module 40 and control device 50 can perform a software check to ensure the software is not corrupt, complete and up to date. If the data is incorrect the control device 50 can initiate a corrective action, which may include downloading the most recent software update available in the platform 30, or reverting to a previous version if the software is not working correctly. Once the software has been installed and is functioning correctly the system moves to step 340, wherein the system is returned to the customer mode once again locking the module settings. It is also noted that the control device 50 may also be configured to return the module to the set-up mode to allow the initial setting to be altered. This may be used if the initial settings are incorrect or in cases where the module 40 has been damaged resulting in the settings being reset. By using a system with the modes described above the module can be configured to limit functionality based on the vehicle's current state reducing the risk of the malfunction due to setting changes. This reduces the risk of faults in the module when in use and provides a means that ensures only authorised personnel can change the module 40 settings. By using this system, the user is provided with a means to easily manage the software in a vehicle, such as a car, wherein the software is updated as a background process reducing the amount of downtime required to update the vehicle. This system also provides a means to monitor and correct the software reducing the risk of software errors thereby making the vehicle computer system more reliable. Further the use of a central platform also the system to provide more secure communications, which are easily directed to specific modules thereby reducing the amount of unnecessary communication and making the process more efficient.

Claims

1. A vehicle software module, comprising:A housing which can be installed into the vehicle;A processing chip within the housing is configured to be coupled to the vehicle's onboard computer system;Wherein the chip is configured to:Establish a communication link with a remote system storing the vehicle software;Download software and software updates for the vehicle computer system from the remote system onto the chip;Install the software update onto the vehicle computer system without disrupting the vehicle operations.

2. The vehicle software module of claim 1, wherein the chip is further configured to receive notifications indicating when a software update has been made available, and on receiving the notification the chip is configured to initiate the download of the software update.

3. The vehicle software module of claims 1 and 2, wherein the chip is configured to analyse the stored software to detect if the data is corrupted, and on detecting the data is corrupted initiate another download of the software update to replace the corrupted version.

4. The vehicle software module of any preceding claim, wherein the chip is configured to analyse the stored software to detect if it is erroneous, meaning it causes errors in the computer system or is incompatible, If the software is erroneous the chip will re-install the previous version of the software.

5. The vehicle software module of claim 4 wherein the module is configured to test compatibility by sending test signals to each vehicle component that the software is configured to control or operate to ensure the components are present.

6. The vehicle software module of any preceding claim wherein the chip is configured to switch between different modes, wherein the modes comprise:Initial / setup mode wherein the details of the vehicle the chip is used for is inputted and the initial software download is installed;Maintenance / repair mode wherein the chip performs an analysis of the stored software such that the user can check the software is up to date, and initiate the installation of new software, when necessary,Customer / drive mode wherein the chip is configured to update software automatically and the user cannot change the chip settings nor can the user alter the software stored in the chip.

7. The vehicle software module of claim 6 wherein the Maintenance / repair mode of the module is configured to send test signals from the vehicle computer system to the vehicle components to check for system damage.

8. The vehicle software module of claims 6 and 7 wherein the module is configured to be coupled to a paired device, and wherein the module can only change modes when coupled to the paired device.

9. The vehicle software module of claim 8, wherein the module comprises a port configured to receive a coupling wire from the paired device.

10. The vehicle software module of claim 9 wherein the module port is an OBD connector.

11. The vehicle software module of any preceding claim, wherein the module is configured to store a module ID, wherein the module ID comprises elements indicating the vehicle the module is coupled to and / or the remote system from which software is received.

12. The vehicle software module of any preceding claim, wherein the module is configured to store a software ID, wherein the software ID indicates the software that was most recently installed within the module; and wherein the ID comprises elements indicating the software version and / or when the software was made available to download.

13. A control device configured to be paired with the vehicle software module of claims 1 to 12, wherein the device is configured to be coupled with the module such that the device and module can exchange information, the device comprising:An interface configured to display information from the module such as the module settings, the software stored in the module, and the results of any analysis performed by the module; andControls configured to receive user inputs to alter the module mode, change the settings of the module and send commands to the module to initiate software downloads and installations.

14. The control device of claim 13, wherein the device comprises a cable that is configured to be coupled to a corresponding port in the module to couple the device to the module.

15. The control device of claims 13 and 14, wherein the interface is configured to display the module ID and the stored software ID when present in the module.

16. An internet platform configured to manage the communications of the module of claims 1 to 12, wherein the platform is configured to establish communication links between the module and the remote system;Wherein the platform is configured to receive and store the software and software updates from the remote system;The platform is configured to receive communications from the module indicating that a software download has been initiated; andWherein the platform is configured to transmit the stored software and software update to the module when a download is initiated.

17. The platform of claim 16, wherein the platform is configured to receive software from multiple remote systems and is configured to pair the module to the software from a specific remote system based on the module settings.

18. The platform of claims 17, wherein the platform is configured to store the module IDs and software IDs, wherein the platform is configured to pair the module to a remote system based on elements within the stored IDs.

19. A system for managing software updates in a vehicle comprising:the vehicle software modules of claims 1 to 12,the control devices of claims 13 to 15 are configured to allow authorised personnel to change the mode and settings of the modules;the platform of claims 16 to 18 is configured to provide software to the modules and to provide communication to the modules indicating when a new software update has been made available; andone or more remote systems configured to provide software and software updates to the platform and to provide a communication to the platform for when a software update has been made available.

20. A method of using the module of claims 1 to 12 wherein the module is installed in a vehicle and receives initial vehicle specific settings and establishes a communication pathway with a remote system;Receiving, via the module, software for the vehicle computer system via the remote system;Installing the received software into the vehicle computer system via the module;Receiving, via the module communication indicating that the installed software has been updated;Downloading the updated software from the remote system onto the module;Installing the software update onto the vehicle computer system when the vehicle is not being operated or when the computer system is inactive.

21. the method of claim 20, further comprising the steps of setting the module into a first mode when inputting the initial settings,Changing the module into a second mode when installing the initial software, this mode may also be used to change the software stored in the module and installed on the vehicle computer system;Changing the module into a third mode when the module is set up to prevent setting and software changes.

22. The method of claim 21, further comprises the steps of coupling a control device to the module, wherein the control device is configured to change the module mode, change the module setting and initiate software downloads to download software onto the module and / or install the downloaded software into the vehicle computer system.

23. The method of claims 20 to 22, wherein the method further comprises forming a communication link between the module and the internet platform;Forming a communication link between the internet platform and a plurality of remote systems,Receiving via the platform a plurality of vehicle software,Pairing the module with one of the stored vehicle software,Downloading the paired vehicle software to the module via the platform.