A method for automatically transforming a message written in a first version of a program into at least a message written in a second version of the program

Abstract

A method for automatically transforming a message 12 written in a first version 14 of a program into at least a message 16 written in a second version 18 of the program by an electronic computing device 10 comprises: generating at least a first transformation code 20 depending on a difference between the first version 14 of the program and the second version 18 of the program by the electronic computing device 10; and providing the second version 18 of the program with the first transformation code 20; and transforming the message 12 into the second version 18 by using the first transformation code 20. There may also be a third version 22 of the program, and a second transformation code 24 for obtaining a message 26 written in the third version. The second version of the program may be tested for the presence of the first transformation code, and it may be discarded if the test fails. The first transformation code may be generated depending on changes of meta versions. The invention may relate to annotated sensor data from a self-driving vehicle, and making use of it for as long as possible during a development stage.

Description

FIELD OF THE INVENTION

[0001] The present invention relates to the field of automobiles. More specifically, the present invention relates to a method for automatically transforming a message written in a first version of a program into at least a message written in a second version of the program by an electronic computing device. Furthermore, the present invention relates to a corresponding computer program product, a corresponding non-transitory computer-readable storage medium, as well as to a corresponding electronic computing device. BACKGROUND INFORMATION

[0002] According to the state of the art, there is a challenge for aligning both a writer and a reader of a communication structure. One way of aligning writers and readers of such a data format is to hard-code such physical and semantic structures into code and synchronize a software rollout to writers and readers. That is, all readers and writers are always on the same software version, naturally having the same understanding of the messages. Such synchronization is preferred because it is the most efficient method. However, it can only be applied when all devices that the software runs on are under full control of the software release process.

[0003] Where it breaks down is if a communication with things outside of the car is provided. A common use case for this is to store for example sensor data from selfdriving vehicle, have humans look over the data and annotate which sensor measurements, for example which pixels in a camera picture, which lidar points, constitute one object, for example a pedestrian or a car. That is very labor intensive and thus expensive. Since it is so expensive, there is a need to make use of that data as long as possible during the development stage and beyond. During development, there is a need to be able to change the physical structure and semantics of a message to improve the system. So then there might be written data in version 3, but during development there is the need to keep reading the version 3 data, even though the readers go through multiple iterations of message versions. SUMMARY OF THE INVENTION

[0004] It is an object of the present invention to provide a method, a corresponding computer program product, a corresponding non-transitory computer-readable storage medium, as well as a corresponding electronic computing device by which aligning of message versions is provided.

[0005] This object is solved by a method, a corresponding computer program product, a corresponding non-transitory computer-readable storage medium, as well as a corresponding electronic computing device according to the independent claims. Advantageous forms of embodiments are presented in the dependent claims.

[0006] One aspect of the invention relates to a method for automatically transforming a message written in a first version of a program into at least a message written in a second version of the program by an electronic computing device. At least a first transformation code is generated depending on a difference between the first version of the program and the second version of the program by the electronic computing device. The second version of the program is provided with the transformation code by the electronic computing device and the message written in the first version of the program is transformed into the second version of the program by using the transformation code by the electronic computing device.

[0007] Therefore, an arbitrary code is written to transform from, for example, version A messages to version B messages. Additionally, transformation chains are added. This means that such transformation code is developed each time the versions are changed and then automatically change the applications of those transformations. According to an embodiment at least a third version of the program is provided and a second transformation code is generated depending on a difference between the second version of the program and the third version of the program by the electronic computing device.

[0008] In another embodiment the message written in the first version of the program is automatically transformed into a message written in the third version of the program by using the first transformation code and the second transformation code.

[0009] In another embodiment at least the second version of the program is tested for the presence of the first transformation code.

[0010] In another embodiment, if the test fails, the second version of the program is discarded.

[0011] In another embodiment the first transformation code is additionally generated depending on changes of meta versions.

[0012] In particular, the method is a computer-implemented method. Therefore, another aspect of the invention relates to a computer program product comprising program code means for performing a method according to the preceding aspect.

[0013] Another aspect of the invention relates to a non-transitory computer-readable storage medium comprising at least the computer program product according to the preceding aspect.

[0014] A still further aspect of the invention relates to an electronic computing device for automatically transforming a message written in a first version of a program into at least a message written in a second version of the program, wherein the electronic computing device is configured for performing a method according to the preceding aspect. In particular, the method is performed by the electronic computing device.

[0015] The electronic computing device / computing unit therefore may comprise electronic means, for example, processors, circuits, in particular integrated circuits, and further electronic means for performing a method. A computing unit may in particular be understood as a data processing device, which comprises processing circuitry. The computing unit can therefore in particular process data to perform computing operations. This may also include operations to perform indexed accesses to a data structure, for example a look-up table, LUT.

[0016] In particular, the computing unit may include one or more computers, one or more microcontrollers, and / or one or more integrated circuits, for example, one or more application-specific integrated circuits, ASIC, one or more field-programmable gate arrays, FPGA, and / or one or more systems on a chip, SoC. The computing unit may also include one or more processors, for example one or more microprocessors, one or more central processing units, CPU, one or more graphics processing units, GPU, and / or one or more signal processors, in particular one or more digital signal processors, DSP. The computing unit may also include a physical or a virtual cluster of computers or other of said units.

[0017] In various embodiments, the computing unit includes one or more hardware and / or software interfaces and / or one or more memory units.

[0018] A memory unit may be implemented as a volatile data memory, for example a dynamic random access memory, DRAM, or a static random access memory, SRAM, or as a non-volatile data memory, for example a read-only memory, ROM, a programmable read-only memory, PROM, an erasable programmable read-only memory, EPROM, an electrically erasable programmable read-only memory, EEPROM, a flash memory or flash EEPROM, a ferroelectric random access memory, FRAM, a magnetoresistive random access memory, MRAM, or a phase-change random access memory, PCRAM.

[0019] Further advantages, features, and details of the invention derive from the following description of a preferred embodiment as well as from the drawing. The features and feature combinations previously mentioned in the description as well as the features and feature combinations mentioned in the following description of the figure and / or shown in the figure alone can be employed not only in the respectively indicated combination but also in any other combination or taken alone without leaving the scope of the invention. BRIEF DESCRIPTION OF THE DRAWING

[0020] The novel features and characteristic of the disclosure are set forth in the appended claims. The accompanying drawing, which is incorporated in and constitutes a part of this disclosure, illustrates exemplary embodiments and together with the description, serves to explain the disclosed principles. The same numbers are used throughout the figure to reference like features and components. Some embodiments of system and / or methods in accordance with embodiments of the present subject matter are now described below, by way of example only, and with reference to the accompanying figure.

[0021] The drawing shows in:

[0022] Fig 1 a schematic flow chart according to an embodiment of the invention.

[0023] In the figure the same elements or elements having the same function are indicated by the same reference signs. DETAILED DESCRIPTION

[0024] In the present document, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration". Any embodiment or implementation of the present subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

[0025] While the disclosure is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawing and will be described in detail below. It should be understood, however, that it is not intended to limit the disclosure to the particular forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternatives falling within the scope of the disclosure.

[0026] The terms “comprises”, “comprising”, or any other variations thereof, are intended to cover a non-exclusive inclusion so that a setup, device or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus preceded by “comprises” or “comprise” does not or do not, without more constraints, preclude the existence of other elements or additional elements in the system or method.

[0027] In the following detailed description of the embodiment of the disclosure, reference is made to the accompanying drawing that forms part hereof, and in which is shown by way of illustration a specific embodiment in which the disclosure may be practiced. This embodiment is described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense.

[0028] Fig. 1 shows a schematic flow chart according to an embodiment of a method. In particular, Fig. 1 shows schematically an electronic computing device 10. The electronic computing device 10 is configured for automatically transforming a message 12 written in a first version 14 of a program into at least a message 16 written in a second version 18 of the program by the electronic computing device 10. At least a first transformation code 20 is generated depending on a difference between the first version 14 of the program and the second version 18 of the program by the electronic computing device 10. The second version 18 is provided with the transformation code 20 by the electronic computing device 10 and the message 12 written in the first version 14 of the program is transformed into the second version 18 of the program by using the transformation code 20 by the electronic computing device 10.

[0029] Furthermore, Fig. 1 shows that at least a third version 22 of the program is provided and a second transformation code 24 is generated depending on a difference between the second version 18 and the third version 22 of the program by the electronic computing device 10. The message written in the first version 14 of the program is automatically transformed into a message 26 written in the third version 22 of the program by using the first transformation code 20 and the second transformation code 24.

[0030] In particular, Fig. 1 shows that writing an arbitrary code to transform the message 12 in the first version 14 into the message 16 in the second version 18. Therefore, the concept of transformation chains, in particular shown with the first transformation code 20 and the second transformation code 24, is added. This means that the development of such a transformation code 20, 24 is enforced each time the versions are changed and then automatically the change application of those transformations. Code development is typically done via code reviews. A developer develops a change to code. When the developer thinks that a code change is ready to be applied to the product, in particular a merge-to-master, they have to review it. When such a review is started, typically automated tests start to test the code change as well. Only if all such tests and reviews pass, the code change is allowed to be merged. Therefore a test to these review tests is added, which verifies that if a version change in any message occurred, and transformation code 20, 24 was added to transform from the prior version to the new version. If that code does not exist, the code change is not allowed to be merged. This is how it is to be ensured that there is a complete transformation chain between any old version and the new version.

[0031] Furthermore, with the invention also meta version changes are solved. So far, it has only been mentioned that the versioning of individual messages may be changed. It has been pretended that there is only one message type in a motor vehicle ever. However, in reality, different components communicate with different message types. For example, the concept of communication channels is provided, where publishers publish messages to a channel and subscribers subscribe to the messages. All messages on one channel are of one type. Therefore, there are multiple channels with the same message type. For example, multiple lidar sensors may publish the same message type, but on different message channels. Each lidar sensor typically has its own message channel for example “lidar / front left”.

[0032] Now over time, either there might be channel changes in the names or channel removements or channel additions. Therefore, also the change in the timing behavior may be solved. For example lidar one used to send measurements every 10 ms but now it sends them every 20 ms. This problem is also solved by the transformation code 20, 24.

[0033] Now, for example only, a code according to an embodiment of the invention is shown. This is an example of one concrete transformation step.

[0034] The message is migrated from type: aracom_interface_planning_aracom_interface_planning__BehaviorTarget_FROM to type: aracom_interface_planning__BehaviorActionlnterface_TO where some fields are different: the type of field behavior_target changed.

[0035] That transformation is delegated to a generic ‘migrate’ function which lives in another file: / / md5sum: 48dd2a879799'Va22f 6f 9056ca4ef 6ac2 / / ROS md5sum: b017bb3fd9b48889fd7f84b8c5b6024f struct aracom_interface_planning__BehaviorActionlnterface_T0 { _ _ _ aracom_interface_planning_aracom_interface_planning__Behavior Target_TO behavior_target; uint8 behavior_type; bool is_safe_default; int32 behavior_search_id; aracom_interface_planning_aracom_interface_planning__HMIInfo hmi info; enum uint8 BehaviorType_kLaneFollowing = 0; enum uint8 BehaviorType_kPrepLaneChange = 1; enum uint8 BehaviorType_kLaneChange = 2; enum uint8 BehaviorType_kTrackGap = 3; enum uint8 BehaviorType_kHoldBrake = 4; enum uint8 BehaviorType_kCreepForward = 5; enum uint8 BehaviorType_kFallback = 6; enum uint8 BehaviorType_kParkGear = 7; enum uint8 BehaviorType_kInvalid = 8; enum uint8 BehaviorType_kNumBehaviorType = 9; aracom_interface_common_aracom_interface_common__Header header; void update(ref const(FROM) from, const (string) topic) { / * Note that this function may be * called during the migration of a parent type. * / / / None of the fields of this type has a direct change migrate(behavior_target, from.behavior_target, topic); behavior_type = from.behavior_type; is_safe_default = from.is_safe_default; behavior_search_id = from.behavior_search_id; migrate(hmi_info, from.hmi_info, topic); migrate(header, from.header, topic); } static void updateROSMessageHeader(ref const(FROM) from, ref string topic, ref int64 time) { / *This function is called * before the update () function is called. * * a) You can leave the 'topic' parameter unmodified * b) You can change the topic of this message by changing 'topic' * c) You can remove this message by setting 'topic' to empty string * * DO NOT CHANGE the parameters if this is a sub-type. * / } } / / / / / / If there is no 'FROM' or 'TO' appended to a struct name, then there / / was no change to that type. / / / / DO NOT CHANGE ANYTHING BELOW THIS LINE / / (except for ad-hoc migration or to remove injected compilation errors) / / / / ----------------------------------------------------- / / md5sum: 36b071a48998c0861688e2217c89dafc / / ROS md5sum: 0b85643c317eeb5dc0al77581e8090cc Signs electronic computing device message first version message second version first transformation code third version second transformation code message

Claims

1. A method for automatically transforming a message (12) written in a first version (14) of a program into at least a message (16) written in a second version (18) of the program by an electronic computing device (10), comprising the steps of: - generating at least a first transformation code (20) depending on a difference between the first version (14) of the program and the second version (18) of the program by the electronic computing device (10);- providing the second version (18) of the program with the first transformation code (20) by the electronic computing device (10) and- transforming the message (12) written in the first version (14) of the program into the second version (18) of the program by using the first transformation code (20) by the electronic computing device (10).

2. The method according to claim 1, characterized in thatproviding at least a third version (22) of the program and generating a second transformation code (24) depending on a difference between the second version (18) of the program and the third version (22) of the program by the electronic computing device (10).

3. The method according to claim 2, characterized in thatthe message (12) written in the first version (14) of the program is automatically transformed into a message (26) written in the third version (22) of the program by using the first transformation code (20) and the second transformation code (24).

4. The method according to any one of claims 1 to 3, characterized in thatat least the second version (18) of the program is tested for the presence of the first transformation code (20).

5. The method according to claim 4, characterized in that,if the test fails, the second version (18) of the program is discarded.

6. The method according to any one of claims 1 to 3, characterized in thatthe first transformation code (20) is additionally generated depending on changes of meta versions.

7. A computer program code comprising program code means for performing a method according to any one of claims 1 to 6.

8. A non-transitory computer-readable storage medium comprising at least the computer program product according to claim 7.

9. An electronic computing device (10) for automatically transforming a message (12) written in a first version (14) of a program into at least a message (16) written in a second version (18) of the program, wherein the electronic computing device (10) is configured for performing a method according to any one of claims 1 to 7.

Images