Distributed network system and vehicle

Abstract

A distributed network system (11) comprising: a back-office server (14) with a first telematics network (15) and a remote calibration tool (140); and a population of host systems (120) in wireless communication with the back-office server (14), each corresponding host system (120) of the population of host systems comprising a second telematics network (15), the second telematics network comprising: an electronic control unit, ECU (16) configured for remote communication with the back-office server (14); and one or more devices (22) controlled by corresponding software code;wherein the back-office server (14) is configured to transmit an over-the-air software update, OTA software update (20), to the ECU (16) of a predetermined one or more of the host systems (120) in response to a configuration signal, and wherein the ECU (16) is configured to selectively mask or unmask a software partition of the corresponding software code in response to the OTA software update (20) in order to disable or enable a function of the one or more devices (22) accordingly, wherein the software partition is marked by the masking using a bit, a bit sequence or an identifier indicating that the software partition has been masked.

Description

introduction

[0001] This disclosure relates to automated systems and methods for proactively implementing software updates, calibrations, and potential error codes. Mobile and stationary host systems of various types increasingly contain complex electronics and software that sometimes require updates. On board a vehicle, for example, the software controlling vehicle systems and components such as the powertrain, battery systems, power electronics, airbags, anti-lock braking systems, and navigation / infotainment systems may occasionally require calibrations or updates. For instance, previously loaded software may be updated when improvements or corrections are made, or when new software versions are released.These adjustments, which can be made automatically via the Internet or another suitable network connection as "over-the-air" updates (OTA updates), serve to maintain the proper functioning of the vehicle.

[0002] Over-the-air (OTA) updates in a representative vehicle application typically occur automatically in the background without affecting current functionality. Such downloads are paused as needed based on network connectivity, download size, and other factors. Software updates are installed later when the vehicle is not in operation, i.e., when it is parked and not running. In this way, OTA updates and revision changes are largely transparent and unobtrusive. However, existing approaches for updating host systems within a networked population of host systems can be suboptimal in some respects, such as updating or calibrating the software of individual vehicles during manufacturing, transport to a dealership, sale, or customer use after the sale. Description

[0003] This document describes systems and procedures for providing robust fault indication containment and software revision control on board a host system within a distributed network. The host system is represented here as a vehicle with a telematics control platform, which, for simplicity, is referred to as the Electronic Control Unit (ECU). The approach described below enables over-the-air (OTA) control of software calibrations and updates, as well as, if required, control of customer-visible fault indications such as diagnostic trouble codes (DTCs). Vehicle functionality is proactively and intelligently corrected by the ECU through automatic remote identification, classification, and adjustment of software parameters.In the non-restrictive vehicle implementations, the revealed solutions eliminate the need to manually detect and individually configure vehicle populations, thereby reducing instances of human error, the recording of false fault modes, and unnecessary dealer repair visits.

[0004] In particular, a distributed network is disclosed herein, comprising (1) a node in the form of a back-office server and (2) one or more nodes in the form of a population of host systems in wireless communication with the back-office server. The back-office server comprises a first telematics network with a remote calibration tool. Each host system comprises a second telematics network. Each second telematics network, in turn, contains an ECU configured to communicate with the back-office server, as well as one or more devices controlled by appropriate software code. In this embodiment, the back-office server is configured to transmit an over-the-air (OTA) software update to one or more predetermined host systems, for example, in response to receiving a configuration signal.The ECU responds to the OTA software update by selectively masking or unmasking a software partition of the corresponding software code to disable or enable a function of one or more devices.

[0005] In response to the OTA software update, the ECU can temporarily disable a diagnostic trouble code (DTC) associated with the function of one or more devices. In one or more implementations, the ECU can also determine a confidence score indicating the probability that the OTA software update corrected a fault in the corresponding software code and can unmask the software partition if the confidence score exceeds a confidence threshold.

[0006] In one or more embodiments, the ECU can also compare a flag in the OTA software update with a flag in the software partition to determine whether the OTA software update is intended to correct a fault in the software partition. The ECU can then unmask the software partition if the flag in the OTA software update matches the flag in the software partition. The ECU can additionally upload a set of host system updates to the back office, where the host system update set includes an updated status of the software partition.

[0007] The embodiments of the back-office server described herein may include a graphical user interface (GUI) as part of the first telematics network. In such a configuration, the remote calibration tool is accessible to a user of the back-office server via the graphical user interface.

[0008] The ECU can be configured to selectively unmask the software partition of the corresponding software code in response to an OTA software update containing an updated software version, thus enabling the functionality of one or more devices. The ECU of each host system can be configured identically, with the back-office server, in turn, configured to deliver the OTA software update to a subset of the host systems within the host system population based on the configuration signal.

[0009] Furthermore, a method for use with a distributed network system is disclosed herein. According to one embodiment, and in response to a configuration signal, the method can include transmitting an over-the-air (OTA) software update to one or more host systems. This is done via a back-office server, the back-office server having a first telematics network that includes a remote calibration tool. The method includes selectively disabling or enabling a function of one or more devices of a host system in response to the OTA software update. This can include selectively masking or unmasking a software partition of corresponding software code via an electronic control unit (ECU) of a second telematics network of a host system. The second telematics network communicates wirelessly with the first telematics network of the back office.

[0010] Also disclosed herein is a vehicle that communicates with a back-office server in a distributed network, in this case a vehicle network or a population of vehicles. The vehicle includes an ECU configured to communicate with the back-office server via the vehicle's telematics network. The vehicle also includes one or more devices controlled by corresponding software code. In this embodiment, the ECU is configured to receive an over-the-air (OTA) software update from the back-office server. In response to the OTA software update from the back-office server, the ECU selectively masks or unmasks a software partition of the corresponding software code to disable or enable a function of the one or more devices of the vehicle.This action may involve temporarily disabling or enabling a DTC associated with the function of one or more of the vehicle's devices.

[0011] The above and other features and advantages of this disclosure will become readily apparent from the following detailed description of illustrative examples and methods for carrying out the present description when considered in conjunction with the accompanying drawings and claims. Furthermore, this disclosure expressly includes combinations and subcombinations of the elements and features described above and below. Brief description of the drawings Fig. Figure 1 shows an illustration of a distributed network with a back-office server and a population of host systems, the latter being configured with the containment and software revision control functions described here. Fig. Figure 2 is a block diagram of a representative telematics system that is on board each of the host systems of Fig. 1 can be used. Fig. Figure 3 is a flowchart illustrating a procedure for carrying out containment and software revision control according to one embodiment.

[0012] The present disclosure can be modified or embodied in alternative embodiments, representative embodiments of which are shown in the drawings and described in detail below. Inventive aspects of the present disclosure are not limited to the disclosed embodiments. Rather, the present description is intended to cover alternatives that fall within the scope of the disclosure according to the appended claims. Detailed description

[0013] Referring to the drawings, where the same reference numerals refer to the same features in the different views, shows Fig. 1 a population 10 of host systems 120 in networked communication with an offboard application or cloud computing service, hereinafter referred to as the back-office server 14. The various host systems 120 and the back-office server 14 together form computer-based communication nodes of a distributed network system 11. In the various, non-limiting embodiments described below with reference to the Fig. As described in 1-3, the host systems 120 are configured as vehicles 12, e.g., as passenger cars, as in Fig. 1 shown, or as trucks, work vehicles, agricultural vehicles, etc. Alternative host systems 120A can be residential buildings 220, sales offices, manufacturing or factory buildings 320, aircraft 420, boats 520, equipment 620, and the like. The vehicles 12 are described below for illustrative purposes only, without limiting the present description to mobile or vehicle-based applications.

[0014] For each of the in Fig. The vehicle's make- and model-specific software can be downloaded or updated during the vehicle's operational life, e.g., in factory hall 320 during manufacturing, during transport of the vehicle 12 to a sales location, at a repair location, or at any time while the vehicle 12 is in use by the customer. The software can be updated as a complete replacement, a revision change, or by removing parts of the previously loaded software. In some cases, the software may contain machine-readable code that can be read by the relevant electronic control units (ECUs) 16 ( Fig. 2) of a specific vehicle 12. Other software components may include calibration, configuration and / or performance information, manifests, infotainment system catalogs and the like, which in turn are used to control a function of one or more devices 22 ( Fig. 2) of vehicle 12 can be used on board vehicle 12.

[0015] In particular, Over-the-Air Updates 20 (OTA Updates 20) are transmitted from the Back-Office Server 14 and ultimately downloaded (arrow DD), enabling vehicle manufacturers 12 to apply OTA software updates 20 remotely / from a distance of potentially hundreds of kilometers or more, thus allowing vehicle owners / operators 12 to avoid unnecessary repair visits to the dealership. Each vehicle 12 can, in turn, selectively transmit OTA system updates 200 to the Back-Office Server 14 according to the disclosure aspects described below. The OTA system updates 200 are, in this case, uploads that propagate in the opposite direction to the downloads from the Back-Office Server 14 and are therefore in Fig. 1 marked by the arrow UU to improve clarity.

[0016] With brief reference to Fig. 2 A telematics network 15 of the host, including the ECU 16, acts as the primary wireless communication node for the vehicle 12, with each vehicle 12 having its own telematics network 15 of the host, as shown in Fig. Figure 1 shows the following. The functions are activated via a cellular modem 27, a Wi-Fi module, and other network modules such as a transceiver 28. The host's telematics network 15 is programmed to collect data from a variety of different vehicle-side devices 22, such as engines, electric drive motors, battery systems, inverter modules, etc., as well as components, subcomponents, sensors, navigation systems, infotainment systems, and other possible devices (not shown). The host's telematics network 15 thus enables remote diagnostics and the performance of the aforementioned OTA software updates 20, as well as the various advantages of the onboard solutions presented.

[0017] On board a modern vehicle such as the one in Fig. In the vehicle 12 shown in Figure 1, 5-digit alphanumeric codes, known as Diagnostic Trouble Codes (DTCs), are automatically recorded in response to a detected malfunction or failure. These faults are automatically detected by an on-board diagnostic (OBD) system 24 while the vehicle 12 is in operation. DTCs can be read using a handheld scanner (not shown) by connecting the scanner to an OBD-II port (not shown) located in or on the vehicle 12, for example, under a dashboard or behind a steering column. Each DTC uniquely identifies the specific system in which the fault occurs, such as the powertrain, chassis, air conditioning, communications network, etc., along with a corresponding fault. The use of DTCs thus enables the diagnosis of a wide variety of possible vehicle faults.Such errors can sometimes occur in parts of the aforementioned vehicle software.

[0018] The telematics network 15 of the host of the representative vehicles 12 from Fig. 1 communicates remotely with the back-office server 14, also known in technical jargon as Vehicle Communications Services (VCS). The back-office server 14 sends the OTA software updates 20 to the various vehicles 12 as needed, possibly using configuration signals 14S from a remote calibration tool 140 (see below). That is, each of the vehicles 12 can receive the same updates, different updates, or no updates, depending on the decisions made by the back-office server 14, as described below. As is known in practice, the back-office server 14 includes, for example, ONSTAR. ®, an associated infrastructure for managing, distributing and monitoring the OTA software updates provided via OTA Software Updates 20

[0019] Without the solutions presented here, the OTA software updates 20 would normally be deployed to the vehicles 12 based on a given set of Vehicle Identification Numbers (VINs), and records of the software update data would then be maintained for each of the vehicles 12. An operations team using the back-office server 14 would then manually track the updates for each individual vehicle. With the present approach, many of the tasks for controlling the OTA software updates 20 are shifted to the vehicle 12 and its ECU 16, which perform them with the help of the following, with reference to Fig. The procedure described in section 3 is carried out by 100 himself.

[0020] Although in Fig. 2. Not shown for simplicity, each vehicle can be 12 of Fig. 1. It may also be equipped with hardware components that enable the operation of the telematics functions required here, including, but not limited to, an electronic video display device, a microphone, audio speakers, and various user input controls such as buttons, knobs, pedals, switches, touchpads, and / or touchscreens. A network connectivity interface allows this hardware to send and receive electronic messages and signals with each other and with various systems inside and outside the vehicle, enabling the vehicle to perform 12 different vehicle functions, such as powertrain control, Advanced Driver Assistance System (ADAS) functions, battery management functions, etc. Wireless communication may be based on one or more wireless protocols, such as the IEEE 802.11 protocols, Worldwide Interoperability for Microwave Access (WiMAX), and / or BLUETOOTH™.

[0021] The host's telematics network 15 and its resident ECU 16 can generally consist of one or more processors (P) 25, each of which can be implemented as a discrete microprocessor, an application-specific integrated circuit (ASIC), or a dedicated control module. Instructions embodying a method 100, of which a non-restrictive example is given in Fig. Figure 3 shows that the information can be stored in a tangible, non-volatile, computer-readable storage medium or memory (M) 26 and executed by the processor(s) 25 to perform the indication containment and software revision functions described below. Such memory 26 can be, for example, a CD-ROM, a magnetic disk, an optical storage medium, a solid-state drive (SSD), a hard disk storage medium, a flash memory, a semiconductor storage medium (e.g., various types of RAM or ROM), etc.

[0022] REPRESENTATIVE OPERATING SCENARIO: The following refers to Fig. The approach described in point 3 is best understood using a hypothetical example. For the in Fig. 1. A representative population of 10 vehicles is shown. 12 can be accessed on their ECUs. 16 ( Fig. 2) Different software versions and / or calibrations may have been loaded previously. In other words, each of the 12 vehicles may have different software versions / calibrations. Since a manufacturer produces different vehicle platforms, newer model years, etc., they follow a software development process during which the software developers may discover various problems or brand- or model-specific errors. The 12 vehicles may start with a common / identical software set, but changes / calibrations can spread.

[0023] For a specific vehicle model in the Fig. In the population 10 of vehicles 12 shown in Figure 1, a specific manufacturer may determine that a particular software problem occurs in vehicles 12 of model year (MY) 2023 of nominal model No. 1 and in vehicles 12 of model year 2024 of nominal model No. 2. The remaining vehicles 12 in the population 10 do not exhibit the same problems in this case. One possible reason for this could be that models No. 1 and No. 2 are high-performance vehicles capable of towing high gravitational forces that were not previously considered or achieved. Other vehicles 12 that have the same ECU 16 as in Figure 1 do not exhibit the same problem. Fig. If two vehicles have a different model year (MY) and a less powerful model, the operation of the software might not pose a problem, even when using the same software calibrations. Consequently, using the present method 100, the manufacturer could calibrate different software functions or mask different faults for models 1 and 2 in this example, while leaving the software unchanged in the remaining vehicles 12. Finally, the manufacturer can update the software over the air by using the OTA software updates 20. Fig. 1 and Fig. 2 is used, so models No. 1 and No. 2 will no longer have the problems.

[0024] The selective re-enabling of software functions, errors, etc., is also enabled by procedure 100. To achieve this, there are three possibilities: (1) the software loaded on the vehicle 12; (2) an application in the back-office server 14, i.e., the remote calibration tool 140. Fig. 2, which, as considered herein, is capable of calibrating the software and / or enabling or disabling software bugs; and (3) another application via the remote calibration tool 140 of the back-office server 14, configured to update the software in the vehicle 12 by downloading software packages, e.g., version revisions, as part of the OTA software updates 20 from Fig. 1 and Fig. 2 reflashed.

[0025] Following the example above, the present approach could consist of using the remote calibration tool 140 of the back-office server 14 from Fig. 2 to use to identify vehicles 12 of models MY 2023 No. 1 and MY2024 No. 2 that exhibit a specific software problem, error, or unexpected result. The affected software in these vehicles 12 is then calibrated (disabled or masked) in response to the configuration signals 14S. The flexibility of identifying affected vehicles 12 via the remote calibration tool 140 allows a user of the back-office server 14 to specify a preference for calibrating, for example, MY 2023 and / or MY 2024 vehicles 12, or more specifically, models No. 1 and No. 2 from these model years, or simply vehicles 12 with a specific ECU 16 and software set, via the configuration signals 14S. The same tool would flexibly allow the user of the back-office server 14 to calibrate a specific generation of the host's telematics network 15 ( Fig. 2) to request, again via the configuration signals 14S.

[0026] For this purpose, the remote calibration tool 140 can be implemented as a graphical user interface (GUI) 19 for a back-office network 150, i.e., a network configured similarly to the host's telematics network 15 and therefore equipped with a similar ECU 16, modem 27, and transceiver 28. For the vehicles 12 in population 10 of Fig. 1. The back-office server 14 and its back-office network 150 may therefore appear as another node in a wireless network, albeit one with the intended functions provided by the remote calibration tool 140, as described below.

[0027] Once the problematic software has been masked in this way, the Back-Office Server 14 can also be used to update the existing software, including any potentially masked partitions, with new software. This can be done in two ways. First, a user of the Back-Office Server 14 can track when the vehicles 12 are updated via the OTA software updates 20 and then, using the same calibration tool 140, communicate with the vehicles 12 to undo the previous software calibration / masking. However, this can be relatively difficult to accomplish, as the various applications of the Back-Office Server 14 will need to be synchronized in subsequent years. Second, the Back-Office Server 14 can place flags or identifiers in different partitions of the loaded software and a corresponding flag(s) in the OTA software update 20. If the ECU 16 of Fig. 2. If the corresponding flag(s) in the OTA software update 20 are detected and the flag(s) match those in the current software partition, the ECU 16 can recalibrate the partition to its original configuration. This function allows the user of the back-office server 14 to allow the OTA software updates 20 to be applied over time, with the vehicles 12 automatically restoring the original state that the developers intended before the software problems arose. Similarly, this approach would allow the flags to be omitted from the OTA software updates 20, thus preserving the calibrations, if the specific OTA software updates 20 do not resolve the software problem.

[0028] Now, with reference to Fig. 3. The procedure described above is divided into individual code segments or logic blocks for illustrative purposes. Each block can be executed by the processor(s) of Fig. 1 must be executed to perform the described functions. In general, the ECUs are 16 of Fig. 2 individually configured to communicate with the back-office server 14 during the execution of procedure 100. In one or more embodiments, each ECU 16 and the associated hardware / software of the host's telematics network 15 is configured to execute instructions from memory 26 via processor 25 during vehicle 12 operation. A similar approach can be followed for other host systems 120, 120A.

[0029] Executing the instructions causes the ECU 16 to receive the OTA software update 20 from the back-office server 14. As mentioned above, the OTA software update 20 is configured to perform a function of one of the electronically controlled vehicle systems 22. Fig. 2 is updated, and can be a calibration or a complete software update / revision change, with the type of OTA software update 20 being determined by the users of the back-office server 14 as mentioned above. The ECU 16 can detect if any software partitions or functions associated with the vehicle 12 and the OTA software update 20 were previously hidden. The ECU 16 can also determine a "confidence value" indicating a software fault and a possible corresponding DTC that will be corrected by the OTA software update 20, for example, using sensor data or other criteria, and then selectively restore functions of the affected vehicle systems 22 if the confidence value exceeds a confidence threshold.

[0030] In the Fig. In the embodiment of method 100 shown in Figure 3, and starting with block B101 (“configuration mode”), the ECU 16 initiates Fig. 1 for a corresponding vehicle 12 and / or the back-office server 14 of Fig. 1. An automatic configuration monitoring mode in which the ECU 16, in response to receiving the OTA software update 20 from the back-office server 14, can monitor the resident software for changes. As part of block B101, the ECU 16 can initiate self-monitoring of software partitions for changes. Such software partitions, as considered here, are segments of software code associated with one or more functions on board the vehicle 12, such as the operation of one or more of the vehicle systems 22 described above. In configuration monitoring mode, the ECU 16 can be Fig. 2. Monitor the following for changes compared to a baseline / previously loaded software: block partitions, software versions, and associated bit mappings, e.g., DTCs, System IDS (SIDS), Feature IDS (FIDS), etc. The OTA software update 20, and thus its contents, is determined by the users of the back-office server 14 via the configuration signals 14S to the remote calibration tool 140 (see Fig. 2), as is known from practice. Procedure 100 continues with block B102 while monitoring for changes during OTA software update 20.

[0031] In block B102 (“OTA Update”), the ECU 16 can then initialize tables and function assignments. As part of block B102, the ECU 16 can verify the initial state of the vehicle 12 with respect to a table of its functions. For example, assuming a multitude of N software partitions of such code, each of the N partitions can be assigned to different software parameters and system functions, for example, in one or more lookup tables. The ECU 16 thus assigns each piece of software code to a specific function on board the vehicle 12.

[0032] During block B102, the ECU 16 can detect deviations or "deltas" in, for example, software versions, bit settings, or other relevant software parameters. In other words: (i) the software was originally loaded into memory 26 of the ECU 16 by Fig. 2 or preloaded into other memory locations, e.g., the factory-preset software or the dealer-loaded software, (ii) the software is arranged in a plurality (N) of software partitions, each software partition being associated with one or more onboard functions, such as display settings, powertrain control settings, radio functions, airbag settings, and the like, and (iii) the ECU 16 monitors the software partitions for partition-specific changes that are included in the OTA software updates 20 from the back-office server 14 of Fig. 1 could be included. Procedure 100 continues with block B103 while observation continues.

[0033] Block B103 (“Parameter Δ”) determines whether the ECU 16 has detected a parameter change in the OTA software update 20. Since the ECU 16 knows the existing software properties of the previously loaded software, it can examine each of the different software partitions for changes compared to this baseline. Procedure 100 proceeds to block B104 if the ECU 16 detects that one or more software parameters have changed. Alternatively, if the ECU 16 does not detect such a parameter change, procedure 100 proceeds to block B105.

[0034] In block B104 (“Update”), the ECU 16 next updates the monitored parameters with a corresponding status, the conditions of the change(s), and other relevant information. Block B104 may involve disabling or masking software in one or more software partitions (see above). When this occurs, such partitions may be delimited or “flagged,” for example, with a corresponding bit, bit sequence, or other identifier indicating that the partition has been masked. Procedure 100 then returns to block B102.

[0035] In block B105 (“SW Version Update?”) the ECU displays 16 of Fig. 2. Next, it determines whether a software version has been updated. As is well known in the field, software versions are unique identifiers of a specific version / iteration of a software component. Software versions are typically numbered sequentially, e.g., version 1.0, 1.1, or 1.1.2, indicating a software version (1) and its current iteration (0, 1.1, 1.2). In the same example, an OTA software update 20 could deliver version 2.0, which would be a completely new version that, in this case, would replace the previously loaded "version 1" software. Procedure 100 returns to block B102 if ECU 16 does not detect such a software version change, and alternatively to block B107 if a software version change is detected.

[0036] In block B107 (“Partition flagged?”) from Fig. Step 3 determines whether a software partition has been flagged, for example, as having been modified in any way in block B105. For instance, ECU 16 might record a bit code in memory 26 if a software partition has changed due to a version update. In this case, block B107 might involve checking the recorded bit code against a predetermined value that indicates the changed status. Procedure 100 then proceeds to block B109.

[0037] In block B109 (“assigned to block?”) the ECU 16 begins. Fig. 1. Next, the procedure addresses any issues that may exist in the existing software block / partition. Block B109 determines whether the flagged software partition is associated with a block of code in the OTA software update 20. As part of Block B109, the ECU 16 can therefore compare the received OTA software update 20 with existing code to determine if a parameter of the received software is associated with the flagged partition or software block from Block B107 of Procedure 100. As mentioned above, example parameters could include a SIDS, FIDS, or other features or functions of the vehicle 12. Procedure 100 proceeds to Block B111A if the parameter is associated with flagged software from Block B107, and to the analogous Block B111B in the alternative.

[0038] In block B111A (“< CONF?”), it is determined whether the parameter(s) in block B109 are above a confidence threshold. As considered herein, the confidence threshold may comprise a predetermined set of conditions or values ​​associated with the parameter(s) from block B109. In general, if the confidence threshold is exceeded, ECU 16 determines that it is safe to enable certain functions. Other examples might include emergency functions or higher-priority functions. In this case, procedure 100 continues with block B112.

[0039] Block B111B (“> CONF?”) is analogous to Block B111A and involves determining whether the parameter(s) of the flagged partition of Block B107, which are not associated with the parameters of Block B109, nevertheless exceed the specified confidence threshold. The confidence threshold may include a predetermined set of conditions or values ​​associated with the parameter(s) from Block B107, as mentioned above in the description of Block B111A. Procedure 100 then proceeds to Block B114.

[0040] Block B112 (“Self-Healing (SH)”) involves the ECU 16 entering a “self-healing” mode. During SH mode, the ECU 16 can be… Fig. Two actions are triggered to correct incorrect or temporary values ​​as soon as they are detected. In this way, the ECU 16 is able, to a certain extent, to restore a previously masked software partition and its associated functionality, including the possible reactivation of DTCs that were previously faulty but may now be valid in light of the OTA software update 20. As part of block B112, the SH mode can enable selective toggling or control of customer-visible fault indicators on board the vehicle 12. The procedure then transitions to block B116.

[0041] Block B114 (“Auto-Config (AC)”) involves entering an “Automatic Configuration” mode. In such a mode, the ECU performs 16 steps. Fig. 2. No self-healing measures are performed to restore previously hidden software functions, as in block B112, but the presence of new functionality is detected based on the flagged block of code (B107) and the presence of unconfigured settings. Procedure 100 then continues with block B116.

[0042] In block B116 (“Notify (14)”), the ECU 16 notifies the back-office server 14 of the Fig. 1 and Fig. 2 about the current parameter status, updates a stored copy or "digital twin", and may suggest possible corrective actions. Block B116 may involve the selective transmission of a set of updated software parameters to the back-office server 14 when the host system 200 of Fig. 1. The ECU 16 is updated after the installation of the OTA software update 20. Afterwards, procedure 100 returns to block B101.

[0043] Using the procedure 100 of Fig. 3 on board the representative vehicles 12 of Fig. 1. Various rules and conditions, normally applied manually on the back-office server 14, are intelligently applied on board the vehicle 12 by its ECU 16, which interacts with the back-office server 14. This allows the ECU 16 to selectively configure itself or adapt to software code updates if these updates affect previously masked software partitions and associated functions. The ECU 16 could also be aware of features and functional capabilities, such as the vehicle 12's sensor configuration, modules, options, subscription status, etc., before activation. This could be achieved using VIN mapping and table logic. Based on the fulfillment of these conditions, the ECU 16 would generate a confidence score for activating the functionality.

[0044] Among other potential advantages, the present approach enables enterprise-level control across multiple vehicles and the masking of fault indicators at the ECU level. This also allows for the classification of affected vehicles 12 according to a broad vehicle platform down to specific equipment levels, telematics hardware generation, software version, occurrence of live fault codes, or individually by chassis number, and the resolution of fault indicators over-the-air. Implementation of these lessons can take place before the sale, e.g., at the factory, at dealerships, or other locations with available cellular connectivity, or during transport to the dealer parking lot, to initiate remediation with a higher probability of a successful resolution before the vehicle reaches the customer. Trigger points after the sale, such as...Changes to the subscription status or the uploading of live error codes can also be used with greater success due to the reliable mobile connection and the telematics wake-up state.

[0045] The present disclosure can be implemented in many different embodiments. Representative examples of the disclosure are shown in the drawings and are described here in detail as non-restrictive examples of the disclosed principles. For this purpose, elements and restrictions described in the sections "Summary," "Introduction," "Description," and "Detailed Description," but not expressly set forth in the claims, should not be considered to be included in the claims, either individually or collectively, either by implication, by inference, or otherwise.

[0046] For the purposes of this description, the use of the singular includes the plural and vice versa, unless expressly excluded; the terms "and" and "or" apply in both the subjunctive and disjunctive moods; "every" and "all" mean "everyone and all"; and the words "including," "containing," "comprehensive," "exhibiting," and the like mean "including without limitation." Furthermore, words of approximation such as "about," "almost," "essentially," "generally," "approximately," etc., may be used herein to mean "at, close to, or almost at" or "within 0-5% of" or "within acceptable manufacturing tolerances," or logical combinations thereof.

[0047] The detailed description and the drawings or illustrations support and describe the present teaching, but the scope of the present teaching is defined exclusively by the claims. While some of the best modes and other embodiments for carrying out the present teaching have been described in detail, various alternative designs and embodiments for carrying out the present teaching exist, which are defined in the accompanying claims. Furthermore, this disclosure expressly includes combinations and subcombinations of the elements and features shown above and below.

Claims

[1] A distributed network system, comprising: a back-office server with an initial telematics network and a remote calibration tool; and a population of host systems in wireless communication with the back-office server, wherein each corresponding host system of the population of host systems contains a second telematics network, the second telematics network comprising: an electronic control unit (ECU) configured for remote communication with the back-office server; and one or more devices that are controlled by appropriate software code; wherein the back-office server is configured to transmit an over-the-air software update (OTA software update) to the ECU of a predetermined one or more of the host systems in response to a configuration signal, and wherein the ECU is configured to selectively mask or unmask a software partition of the corresponding software code in response to the OTA software update in order to disable or enable a function of the one or more devices accordingly. [2] Distributed network system according to claim 1, wherein the ECU is configured to temporarily disable, in response to the OTA software update, a diagnostic trouble code, DTC, associated with the function of one or more devices. [3] Distributed network system according to claim 1, wherein the ECU is configured to determine a confidence value indicating the probability that the OTA software update has corrected a fault in the corresponding software code, and to unmask the software partition when the confidence value exceeds a confidence threshold. [4] Distributed network system according to claim 1, wherein the ECU is configured to compare a flag in the OTA software update with a flag in the software partition to determine whether the OTA software update is aimed at correcting a fault in the software partition and to unmask the software partition if the flag in the OTA software update matches the flag in the software partition. [5] Distributed network system according to claim 1, wherein the ECU is configured to selectively upload a set of host system updates to the back office, wherein the set of host system updates includes an updated state of the software partition. [6] Distributed network system according to claim 1, wherein the back-office server includes a graphical user interface, GUI, as part of the first telematics network, and wherein the remote calibration tool is accessible to a user of the back-office server via the GUI. [7] Distributed network system according to claim 1, wherein the ECU is configured, in response to the fact that the OTA software update contains an updated software version, to selectively unmask the software partition of the corresponding software code in order to enable the function of one or more devices. [8] Distributed network system according to claim 1, wherein the ECU of each respective host system is configured identically, and wherein the back office is configured to transmit the OTA software update based on the configuration signal to a subset of the host systems in the population of host systems. [9] Vehicle communicating with a back-office server in a distributed network encompassing the vehicle: an electronic control unit (ECU) that is set up to communicate with the back-office server via a vehicle telematics system; and one or more devices of the vehicle that are controlled by a corresponding software code, with the ECU configured as follows: to receive an over-the-air (OTA) software update from the back-office server via the telematics system; and In response to the OTA software update from the back-office server, to selectively mask or unmask a software partition of the corresponding software code in order to disable or enable a function of one or more of the vehicle's devices, including temporarily disabling or enabling a diagnostic trouble code (DTC) associated with the function of one or more of the vehicle's devices. [10] Vehicle according to claim 9, wherein the ECU is configured: to determine a confidence value that indicates the probability that the OTA software update has corrected a bug in the relevant software code; and to unmask the software partition if the confidence value exceeds a confidence threshold.

Images