A method for flashing software to an ECU

Abstract

The invention relates to a method (100) for flashing software, in particular an AUTOSAR stack for automated vehicle communication, onto an ECU (3), in particular of a vehicle (1), comprising the following steps: - receiving (101) data from an external source (40), the data being specific to technical requirements for the AUTOSAR stack; - generating (102) the software, in particular the AUTOSAR stack for automated vehicle communication, based on the data received by a data processing engine (30); - Sending (103) the software to the ECU (3) and saving the software in the ECU (3).

Description

[0001] The invention relates to a method and a system for flashing software, in particular an AUTOSAR stack for automated vehicle communication, onto an ECU, in particular of a vehicle. Furthermore, the invention relates to a computer program and a storage medium for this purpose. State of the art

[0002] Currently, the creation of AUTOSAR vehicle communication features involves a manual approach, which has several disadvantages. These include a significant amount of rework, increased overall production costs and time, quality issues, and delayed time to market. This manual approach can lead to human errors, oversights, and deviations in execution, compromising the performance, safety, and reliability of the AUTOSAR vehicle communication feature. Disclosure of the invention

[0003] The method for flashing software, in particular an AUTOSAR stack for automated vehicle communication, onto an ECU, in particular of a vehicle, comprises the following steps: - Receiving data from an external source, where the data is specific to technical requirements for the AUTOSAR stack; - Generating the software, in particular the AUTOSAR stack for automated vehicle communication, based on the data received by a data processing engine; - Sending the software to the ECU and saving the software in the ECU.

[0004] The term "data" can be understood as referring to information, specifications, or requirements relevant to the developed AUTOSAR stack for automated vehicle communication. This information may include, but is not limited to, technical requirements, configuration settings, parameter definitions, and other details necessary for the proper functioning of the AUTOSAR stack.

[0005] The data may be provided by an external source, such as a human operator, a software tool, or another system. The data may be in various formats, including, but not limited to: * ECU extract file * DBC file * SystemExtract file * Excel file * PDF file * Parameter definition file * File for figure sheets * Properties file * AUTOSAR version information file * AUTOSAR target specification file * Non-AUTOSAR target specification file

[0006] The data may be processed, transformed, or merged into a unified file before being used to generate the AUTOSAR stack. This processing may include parsing, filtering, or mapping the data to a specific format or structure required by the AUTOSAR stack.

[0007] In general, the term "data" is intended to encompass any information relevant to the development and operation of the AUTOSAR automated vehicle communication stack and provided by an external source. The specific nature and content of the data may vary depending on the context and requirements of the system.

[0008] The term "external source" can be understood as any data source that is inherently part of the software being created. In other words, an external source is a source of information that is not resident within the software itself, but is instead obtained from an external location.

[0009] The external source may include, but is not limited to: * ECU extract file: a file that contains information about the ECU hardware and software components used to configure the ECU for the specific application. * DBC file: a file that contains information about the data types and formats used in the AUTOSAR stack. * SystemExtract file: a file that contains information about the vehicle's system architecture and components. * Excel file: a file containing information about the technical requirements for the AUTOSAR stack, such as the required software components, interfaces and data formats. * PDF file: a file containing documentation and specifications for the AUTOSAR stack. * Parameter definition file: a file that contains definitions of the parameters used in the AUTOSAR stack. * Mapping sheet file: a file containing mappings of the data structures and interfaces used in the AUTOSAR stack. * Properties file: A file that contains metadata and other information about the AUTOSAR stack. * AUTOSAR version information file: a file that contains information about the version of the AUTOSAR standard used. * AUTOSAR target specification file: a file that contains information about the target platform and environment for the AUTOSAR stack. * Non-AUTOSAR target specification file: A file that contains information about the target platform and environment for the non-AUTOSAR components of the generated software.

[0010] The external source can be a human-readable file or a machine-readable file, such as an Excel spreadsheet or a PDF document. The external source can be stored on a local or remote storage device, such as a hard drive, a network-attached storage device, or a cloud-based storage service.

[0011] In summary, the term "external source" refers to any data source that is not inherently part of the generated software and may include a variety of files and other information sources used to configure and specify the software.

[0012] The term "technical requirements" can be understood as referring to the specifications, guidelines, and standards that the AUTOSAR automated vehicle communication stack must meet to fulfill its intended function within the vehicle's electronic system. These technical requirements may include, but are not limited to: * Performance requirements, such as processing speed, memory requirements and data transfer rates; * Functional requirements, such as the ability to communicate with other systems and components within the vehicle and to provide specific features and functions for the driver and passengers; * Safety requirements, such as the ability to operate safely and reliably under a wide range of environmental conditions and to respond appropriately to faults and errors; * Compatibility requirements, such as the ability to work with other systems and components within the vehicle and to interface with external systems and devices; * Security requirements, such as the ability to protect the system from unauthorized access and data theft, and to ensure the integrity of the system and its components.

[0013] To meet these technical requirements, the AUTOSAR stack for automated vehicle communication can be designed and implemented using a variety of techniques and technologies, such as: * Software development methods such as Agile and Waterfall; * Programming languages ​​such as C, C++ and Java; * Software frameworks, such as AUTOSAR and other industry-standard frameworks; * Hardware platforms such as microcontrollers, microprocessors and other programmable devices.

[0014] Overall, the term “technical requirements” is intended to encompass all specifications, guidelines and standards that the AUTOSAR stack for automated vehicle communication must meet in order to function effectively and safely within the vehicle’s electronic system.

[0015] The term "AUTOSAR Stack for Automated Vehicle Communication" can be understood as a software system that enables automated communication between a vehicle and other systems or devices, such as sensors, actuators, or other vehicles, based on the AUTOSAR (Automotive Open System Architecture) standard. The stack is "automated" in the sense that it is automatically generated from technical requirements for the AUTOSAR stack, rather than being manually created by a developer.

[0016] The AUTOSAR stack consists of a collection of software components and tools that provide a standardized architecture for automotive software development. It includes a range of software components, such as a runtime environment, a communication protocol, and a set of APIs (Application Programming Interfaces) for accessing the vehicle's hardware and software resources.

[0017] The "vehicle communication" aspect of the term refers to the fact that the stack is designed to enable the vehicle to communicate with other systems or devices, such as sensors, actuators, or other vehicles. This communication can be based on a variety of protocols, such as CAN (Controller Area Network), FlexRay, or Ethernet, and can include the exchange of a wide range of data, such as sensor data, navigation information, or control commands.

[0018] The "AUTOSAR" aspect of the term refers to the fact that the stack is based on the AUTOSAR standard, which provides a set of guidelines and rules for automotive software development. The standard is designed to promote the reuse of software components and facilitate the integration of software from different vendors, which can help reduce the cost and complexity of automotive software development.

[0019] Overall, the term “AUTOSAR stack for automated vehicle communication” can be understood as a software system that enables the automated communication of a vehicle with other systems or devices based on the AUTOSAR standard and that is automatically generated by technical requirements for the AUTOSAR stack.

[0020] The term "data processing engine" can be understood as the software component or module that performs the processing and generation of the AUTOSAR stack for automated vehicle communication based on the received data. The data processing engine is responsible for implementing the specific instructions and algorithms required to generate the software and can be considered the "brain" of the process for flashing the software to the ECU.

[0021] More specifically, the data processing engine may be a software program or a set of instructions executed by a computer or other processing device. The data processing engine may be written in a programming language such as C, C++, Java, or another language commonly used for software development.

[0022] The data processing engine may be configured to perform a variety of tasks, such as parsing and analyzing the received data, generating the AUTOSAR stack based on the data, and sending the software to the ECU. The data processing engine may also be responsible for managing the storage of the software in the ECU and ensuring that the software is properly installed and configured.

[0023] The data processing engine can be implemented using a variety of technologies and architectures, such as a standalone computer or server, a cloud-based service, or a distributed system. The data processing engine can also be integrated with other systems and devices, such as the ECU, to provide a seamless and integrated process for software development and flashing.

[0024] Overall, the term "data processing engine" is intended to encompass a broad range of software and hardware technologies that can be used to generate the AUTOSAR stack for automated vehicle communication and flash it onto the ECU. The data processing engine is a critical component of the process, as it provides the processing power and instructions required to generate the software and execute the other steps of the process.

[0025] The term "ECU" can be understood as a reference to an electronic control unit, which is a computer-based device used in vehicles to control various systems, such as engine management, transmission, brakes, and suspension. ECUs are typically responsible for receiving and processing sensor data, executing control algorithms, and sending commands to actuators to control the vehicle's systems.

[0026] In the context of the present invention, the ECU is the target device for which the software, in particular the AUTOSAR stack for automated vehicle communication, is flashed. The ECU can be any type of computer-based device capable of executing the software and performing the functions described in the claims.

[0027] It is important to note that the present invention is not limited to any specific ECU or vehicle type, and the invention can be applied to any type of vehicle or transportation system that uses an ECU for control. Furthermore, the invention is not limited to the automotive industry and can be applied to other industries that use ECUs for control, such as agricultural vehicles, construction equipment, or industrial machinery.

[0028] In summary, the term "ECU" as used in the claims is intended to refer to any type of computerized device used to control a vehicle or other system, and the present invention is not limited to any specific ECU or vehicle type.

[0029] Advantageously, the method enables the flashing of software, in particular an AUTOSAR stack for automated vehicle communication, onto a vehicle's ECU without requiring manual coding or software configuration. This eliminates the disadvantages of the current manual process, such as efficiency and quality issues.

[0030] Advantageously, the method uses an external source to provide specific data regarding the technical requirements for the AUTOSAR stack, enabling more efficient and accurate software generation. This contrasts with the state of the art, which relies on manually processing input files, including ECU extract, DBC, System Extract, Excel, and PDF files.

[0031] Advantageously, the data processing engine used in the method is capable of generating the software based on the received data, including parameter definitions, mapping, and property files, thereby ensuring a coherent and compatible output. This contrasts with the prior art, which may require manual configuration of the input files and parameters.

[0032] Advantageously, the method allows the software to be sent and stored in the ECU, providing a seamless and efficient installation process. This eliminates the need for manual software installation and configuration, reducing the overall time required for the product development process.

[0033] Compared to the prior art, the present invention provides several technical advantages, including: Advantageously, the invention eliminates the need for manual coding and configuration of the software, thereby reducing the time for the product development process.

[0034] Advantageously, the invention uses an external source to provide specific data regarding the technical requirements for the AUTOSAR stack, thereby enabling more efficient and accurate software generation.

[0035] Advantageously, the invention provides a coherent and compatible output, thereby ensuring that the software is properly configured and functional.

[0036] Advantageously, the invention enables a seamless and efficient installation process, eliminating the need for manual installation and configuration of the software.

[0037] In another aspect of the invention, the step of generating the AUTOSAR stack comprises processing a plurality of data formats of the received data into one, in particular a single, AUTOSAR-specific format via a predefined or definable script.

[0038] The term "multi-format processing" can be understood as the process of converting, transforming, or manipulating multiple data formats into a single, specific format that conforms to the standards and requirements of the AUTOSAR (Automotive Open System Architecture) specification. This process involves the use of a predefined or definable script that enables the conversion of various data formats into a unified format, thus facilitating the creation of the AUTOSAR stack.

[0039] In detail, the term “processing a variety of data formats” includes the following aspects: 1. Multiple data formats: The term implies that the received data can be in different formats, such as ECU extract file, DBC file, SystemExtract file, Excel file, PDF file, parameter definition file, figure sheet file, properties file, AUTOSAR version information file, AUTOSAR target specification file and / or non-AUTOSAR target specification file. 2. Variety of data formats: Data formats can be diverse and not limited to a specific type or category. For example, the received data can contain both technical requirements and parameter definitions in different formats. 3. Single, specific format: The processed data is converted into a single, specific format that conforms to the AUTOSAR specification. This format can be defined by the script used to process the data. 4. Predefined or definable script: The script used to process the data can be predefined or definable, allowing flexibility in the processing procedure.

[0040] In summary, the term "multi-format processing" refers to the conversion of multiple different data formats into a single, specific format that conforms to the AUTOSAR specification, using a predefined or definable script. This process enables the generation of the AUTOSAR stack based on the received data.

[0041] The term "particularly individually" can be understood as referring to the fact that the generated AUTOSAR stack is in a single, specific format defined or definable by a script. This means that the script used to generate the AUTOSAR stack can be adapted to generate a single, uniform format for the stack, rather than generating multiple formats or a generic format.

[0042] In other words, the phrase "specifically individually" emphasizes that the generated AUTOSAR stack is not just a generic format, but a specific, individual format defined or definable by the script. This level of specificity is important because it allows for more precise control over the formatting of the AUTOSAR stack, which can be useful for ensuring the stack is properly configured for the specific requirements of the vehicle's electronic control unit (ECU).

[0043] The term "AUTOSAR-specific format" can be understood as a set of rules, conventions, and protocols that define the structure, organization, and content of data used in the context of the Automotive Open System Architecture (AUTOSAR) standard. This standard is widely used in the automotive industry for the development of software and hardware components of vehicle systems.

[0044] In the context of the present invention, the term "AUTOSAR-specific format" is used to refer to the specific way in which data is formatted and organized for use by the AUTOSAR stack. This includes the use of specific data structures, such as arrays, linked lists, and tables, as well as the use of specific data types, such as integers, floating-point numbers, and strings.

[0045] The AUTOSAR-specific format may also include specific conventions for naming and organizing files, as well as specific protocols for data transfer and communication between system components. These conventions and protocols are designed to ensure that the data used by the AUTOSAR stack is consistent and clearly defined, and that it can be easily integrated into other system components.

[0046] In particular, the predefined or definable script used in the step of creating the AUTOSAR stack may be designed to process the plurality of data formats of the received data into a single AUTOSAR-specific format. This may include converting data from one format to another, such as converting a binary format to a text format, or converting a specific data structure to a more general structure. The script may also be designed to validate the data to ensure that it complies with the requirements of the AUTOSAR standard.

[0047] Overall, the term "AUTOSAR-specific format" is used to refer to the specific set of rules, conventions, and protocols that define the structure, organization, and content of data used in the context of the AUTOSAR standard. This term is used to describe the format of the data processed and generated by the method of the present invention.

[0048] The term "predefined or definable script" can be understood as a computer program or set of instructions used to process a variety of received data formats into a single, specific format for the AUTOSAR stack. This script can be either predefined by the inventor or user-definable, and is used to map the received data to the specific format requested by the AUTOSAR stack.

[0049] The predefined script may be a standard script provided by the inventor and is specific to the AUTOSAR stack and the data formats used in the method. This script may be stored on a storage device and loaded into the data processing engine when the method is executed. The predefined script may be written in a programming language, such as Java, C++, or Python, and may include a series of instructions executed by the data processing engine to process the received data.

[0050] On the other hand, the definable script can be a script generated by the user based on the specific requirements of the AUTOSAR stack and the data formats used in the method. This script can be generated using a scripting language, such as JavaScript, Python, or Ruby, and can be stored on a storage device or manually entered by the user. The definable script can include a set of instructions executed by the data processing engine to process the received data, and it can be modified or adapted by the user to meet the specific requirements of the method.

[0051] In either case, the script is used to process the received data and generate the AUTOSAR stack, and it is an essential part of the process. Using a predefined or definable script allows for flexibility and customization of the process, and it allows for processing a variety of data formats into a single, specific format for the AUTOSAR stack.

[0052] Advantageously, this aspect of the invention provides a method for generating an AUTOSAR stack that can process a variety of received data formats into a single, AUTOSAR-specific format via a predefined or definable script. This offers several advantages over the prior art: 1. Improved data compatibility: By processing a variety of data formats into a single, AUTOSAR-specific format, the invention ensures that all data, regardless of its original format, can be seamlessly integrated into the AUTOSAR stack. This improves data compatibility and reduces the likelihood of errors or inconsistencies. 2. Improved flexibility in scripting: The predefined or definable scripting aspect of the invention enables greater flexibility in scripting, enabling the creation of AUTOSAR stacks that can accommodate a wide range of data formats and inputs. This improves the efficiency and effectiveness of the method, as it can be adapted to specific requirements. 3. Increased automation: By automating the processing of data formats into a single, AUTOSAR-specific format, the claim reduces the need for manual intervention and minimizes the risk of human error. This increases the overall efficiency of the process and improves the consistency of the resulting AUTOSAR stack. 4. Faster development cycles: With the ability to process a variety of data formats into a single, AUTOSAR-specific format, the invention enables faster development cycles and reduced time to market for new products. This is because the method can be applied to a wide range of data formats and inputs, enabling faster prototyping and testing. 5. Improved product quality: By ensuring that all data can be seamlessly integrated into the AUTOSAR stack, the invention improves the overall quality of the product. This is because the method can accommodate a wide range of data formats and inputs, reducing the likelihood of errors or inconsistencies that can affect product performance and reliability.

[0053] In summary, the invention provides a method for generating an AUTOSAR stack that offers improved data compatibility, increased flexibility in scripting, increased automation, faster development cycles, and improved product quality compared to the prior art.

[0054] According to another aspect of the invention, the script is based on Java.

[0055] The term "script" can be understood as a detailed, step-by-step plan or procedure for executing a specific task or set of tasks, in this case, the task of generating the AUTOSAR stack based on the received data. A script is a predefined or definable set of instructions that are executed in a specific order to achieve a specific goal.

[0056] The script is based on Java, providing a robust and versatile platform for developing the script. Using Java ensures that the script is reliable and secure, and that it can be easily integrated into other systems and tools.

[0057] The script may include a variety of instructions, such as reading and parsing data files, processing and manipulating data, and generating output files. The script may also include instructions for error handling and debugging to ensure the process is robust and reliable.

[0058] The script can be written in a specific format, such as a Java class or a Java method, and can include specific syntax and semantics specific to the Java programming language. The script can also be designed to be modular and reusable, allowing it to be easily integrated into other systems and applications.

[0059] Overall, the term “script” in the context of the patent application refers to a detailed, predefined or definable set of instructions that are executed in a specific order to generate the AUTOSAR stack based on the received data and is based on the Java programming language.

[0060] The term "based on Java" can be understood to indicate that the script used to create the AUTOSAR stack is written in the Java programming language. This means that the script is implemented using the Java language and its associated programming paradigms, such as object-oriented programming and the use of Java classes and methods.

[0061] In detail, the term “based on Java” can be interpreted as follows: * The script is written in Java language, a high-level object-oriented programming language commonly used to develop software applications. * The script can use Java language constructs such as classes, objects, procedures and loops to process the data from the external source and create the AUTOSAR stack. * The script can also use Java libraries and frameworks, such as the Java Standard Library, to perform various tasks and functions in the process of building the AUTOSAR stack. * The Java-based script can be compiled and executed by a Java Virtual Machine (JVM) to generate the AUTOSAR stack.

[0062] Overall, the term “based on Java” emphasizes that the script used to create the AUTOSAR stack is implemented using the Java programming language, a widely used and well-established programming language in the field of software development.

[0063] Advantageously, this provides a more efficient way of generating an AUTOSAR vehicle communication feature than the manual method currently used in the industry. 1. Improved efficiency: Using a Java-based script eliminates the need for manual coding, reducing the time and effort required to generate the AUTOSAR model. This significantly reduces the overall product development process, making it more efficient. 2. Increased accuracy: The script ensures that the AUTOSAR model is generated accurately and consistently without the need for manual intervention. This reduces the likelihood of errors and quality issues, leading to improved overall product quality. 3. Increased flexibility: The script can be easily modified to accommodate changes in the input sources, such as new ECUextract or DBC files. This allows for greater flexibility in the product development process and allows for easy adaptation of the AUTOSAR model to changing requirements. 4. Improved scalability: The script can be executed multiple times with different input sources, enabling the generation of multiple AUTOSAR models for different vehicle types or systems. This improves the scalability of the product development process and enables the generation of a wider range of AUTOSAR models. 5. Reduced learning curve: Using a Java-based script reduces the need for specialized knowledge and skills required for manual coding. This makes it easier for developers to learn and use the script.

[0064] In yet another aspect of the invention, the data from an external source comprises at least one of the following: ECU extract file, DBC file, SystemExtract file, Excel file, PDF file, parameter definition file, mapping sheet file, properties file, AUTOSAR version information file, AUTOSAR target specification file, and / or non-AUTOSAR target specification file.

[0065] The term "ECUextract file" can be understood as a file containing information about the technical requirements for an AUTOSAR stack for automated vehicle communication, in particular for a vehicle's ECU (Electronic Control Unit). This file is typically generated by an external tool, such as a configuration tool, and contains data specific to the ECU's technical requirements, including, but not limited to: * The version of the AUTOSAR standard used by the ECU * The target hardware and software environment of the ECU * The communication protocols and interfaces used by the ECU * The data formats and message structures used by the ECU

[0066] The ECU extract file can contain information about the ECU's hardware components, such as the microcontroller or memory, and their configuration. Additionally, the file can contain information about the ECU's software components, such as the operating system and application software, and their interactions.

[0067] The ECUextract file is an important input to the invention because it provides the necessary information to generate the AUTOSAR stack for the ECU. The file can be in a proprietary format specific to the external tool that generated it, or it can be in a standardized format, such as XML or JSON.

[0068] In the context of the present patent application, the ECUextract file is a specific type of data format used to define the technical requirements of an ECU for the purpose of generating an AUTOSAR stack. The file can be generated by an external tool, such as a configuration tool, and can be used as input for the claimed method to generate the AUTOSAR stack.

[0069] The term "DBC file" can be understood as a reference to a specific file type containing data used by the AUTOSAR (Automotive Open System Architecture) standard for vehicle communication. DBC stands for "Data Base Configuration" and is a file that stores configuration data for the communication protocols used in vehicles.

[0070] In the context of the patent application, the DBC file is one of the data types that can be received from an external source and used to generate the AUTOSAR stack for automated vehicle communication. The DBC file contains information about the communication protocols used in the vehicle, such as the message format, data types, and error handling procedures.

[0071] The DBC file is typically generated by an external tool, such as a simulation or testing tool, and is used to configure the communication protocols used in the vehicle. The DBC file can contain information about the message format, such as the structure of the messages, the data types used in the messages, and the error handling procedures used in the event of errors.

[0072] The DBC file is an important part of the AUTOSAR standard and is used to ensure that the communication protocols used in the vehicle are properly configured and functioning correctly. The DBC file is typically included in the ECU extract file, a file that contains all the data required for the ECU (Electronic Control Unit) to function properly.

[0073] The term "SystemExtract file" can be understood as a file containing a set of data and information specific to the technical requirements of an AUTOSAR stack for automated vehicle communication, and is used as input for software generation. The SystemExtract file can contain a variety of data formats, such as Excel files, PDF files, and other file types containing the technical requirements for the AUTOSAR stack.

[0074] The SystemExtract file can contain information such as: * Technical requirements for the AUTOSAR stack, such as the desired performance, safety and security features. * Information about the vehicle's hardware and software components, such as the ECU, sensors and actuators. * Data about the communication protocols and interfaces used by the vehicle, such as CAN, FlexRay and LIN. * Information about the software and hardware components of the ECU, such as the operating system, software libraries and hardware peripherals.

[0075] The SystemExtract file can be generated using a variety of tools and techniques, such as Excel spreadsheets, database management systems, and specialized software tools. The file can be in a structured format, such as a table or matrix, or in an unstructured format, such as a text file.

[0076] The SystemExtract file is an important input to the AUTOSAR stack build process because it provides the technical requirements and information used to build the software. The file can be provided by the vehicle manufacturer, the ECU manufacturer, or another entity with knowledge of the AUTOSAR stack's technical requirements.

[0077] The term "Excel file" can be understood as a file in a specific format created by Microsoft Excel, a spreadsheet software commonly used for data analysis, chart creation, and data visualization. This file format is characterized by the use of Excel sheet files consisting of rows and columns containing data, formulas, and other information.

[0078] In the context of the present invention, an Excel file may contain technical requirements for an AUTOSAR stack for automated vehicle communication, such as parameters, settings, and other information relevant to the development and configuration of the stack. The Excel file may be used as a data source for the process of flashing the software to an ECU and may be processed and merged with other data sources to generate the AUTOSAR stack.

[0079] The Excel file can contain a variety of information, such as: * Parameters and settings for the AUTOSAR stack, such as communication protocols, data formats and other configuration options. * Technical requirements for the ECU, such as memory size, processing power and other hardware specifications. * Information about the vehicle, such as make, model and year, that may be relevant for the development and configuration of the AUTOSAR stack.

[0080] The Excel file can be created using Microsoft Excel or other spreadsheet software, and can be saved to a specific location, such as a shared network drive or a cloud storage service, for access through the software flashing process.

[0081] Overall, the term "Excel file" shall include all files generated by Microsoft Excel or other spreadsheet software that contain technical requirements and other information relevant to the development and configuration of an AUTOSAR stack for automated vehicle communication.

[0082] The term "PDF file" can be understood as a computer file containing a Portable Document Format (PDF) representation of the technical requirements for the AUTOSAR stack. The PDF file may contain text, images, and other multimedia elements that provide detailed specifications for the software components and their interactions within the AUTOSAR stack.

[0083] The PDF file can be created using a variety of tools and techniques, such as PDF creation software or document scanning and conversion tools. The file can be in a specific format and can contain specific information, such as fonts, font sizes, and page layouts, to ensure the document is easy to read and understand.

[0084] The PDF file can be used to provide detailed and comprehensive documentation of the technical requirements for the AUTOSAR stack, which can be useful for developers, engineers, and other stakeholders who need to understand the specifications of the software components and their interactions. The PDF file can be stored on a computer-readable storage medium, such as a hard disk or network server, and can be accessed and viewed using a variety of software tools and applications, such as Adobe Acrobat Reader.

[0085] In the context of the invention, the term "PDF file" is used to refer to a specific type of computer file containing the technical requirements for the AUTOSAR stack in a PDF format. The use of the term "PDF file" is intended to indicate that the data from the external source may include a PDF file containing the technical requirements for the AUTOSAR stack, and that the method of the invention may be used to process and use this data in generating the AUTOSAR stack.

[0086] The term "parameter definition file" can be understood as a document or set of instructions that defines the parameters and their values ​​required for the proper functioning of an AUTOSAR stack for automated vehicle communication. This file contains the information needed to configure the stack's software components to meet the specific requirements of the vehicle's electronic control units (ECUs).

[0087] In particular, the parameter definition file may contain information about the following parameters: * Communication protocols and standards used by the vehicle's ECU * Data formats and message structures exchanged between the ECU and the AUTOSAR stack * Configuration settings for the components of the AUTOSAR stack, such as timers, counters and memory allocations * Setting values ​​for the stack parameters, such as buffer sizes, time constraints and error handling mechanisms

[0088] The parameter definition file can be in a specific format, such as an XML or JSON file, and can be processed by the data processing engine to configure the AUTOSAR stack accordingly. The file can also contain information about the version of the AUTOSAR standard used, as well as any non-AUTOSAR target specifications that must be considered during the software flashing process.

[0089] The term "mapping sheet file" can be understood as a file containing a set of mappings or correspondences between different data structures, formats, or parameters used in the development and implementation of an AUTOSAR stack for automated vehicle communication. The mapping sheet file is typically generated and used during the development process to ensure that the various system components, such as the ECU, the AUTOSAR stack, and any other peripheral systems, are properly configured and integrated to meet the vehicle's technical requirements.

[0090] The figure sheet file can contain a variety of information, such as: * Mappings between the different data formats used in the system, such as the ECU extract file, the DBC file, the SystemExtract file, and any other formats used in the development process. * Correspondences between the different parameters and configurations used in the system, such as the parameter definition file, the figure sheet file, and any other file used in the development process. * Information about the different components of the system, such as the ECU, the AUTOSAR stack and any other peripheral systems, including their technical specifications, configuration parameters and any other relevant information.

[0091] The figure sheet file can be generated using a variety of tools and techniques, such as spreadsheet software, database software, or specialized figure-making tools. The file can be saved in a variety of formats, such as a text file, an Excel file, a CSV file, or any other format that can be easily read and understood by humans and machines.

[0092] The term "properties file" can be understood as a file containing a set of properties or characteristics of the developed AUTOSAR stack. These properties can include information such as the version number of the AUTOSAR standard used, the target hardware platform of the ECU, the ECU's memory layout, and other parameters relevant to the development and operation of the AUTOSAR stack.

[0093] The properties file can be in a specific format, such as an XML or JSON file, and can contain a set of key-value pairs or other data structures that define the properties of the AUTOSAR stack. The file can also contain metadata, such as the date and time of creation or modification, as well as information about the author or owner of the file.

[0094] The properties file is an important part of the development and configuration of the AUTOSAR stack, as it provides a central location for storing and managing the stack's properties and characteristics. By including the properties file as one of the data sources in the claimed invention, the method and system for flashing software to the ECU can exploit the information contained in the file to ensure that the software is properly configured and optimized for the target hardware platform.

[0095] The term "AUTOSAR version information file" can be understood as a digital document that provides information about the version of the AUTOSAR standard used in the development of the software, in particular the AUTOSAR stack for automated vehicle communication, and the target hardware and software environment for which the software is intended. This file may contain information such as the version number of the AUTOSAR standard, the release date, and any relevant notes or comments regarding the software version.

[0096] In particular, the AUTOSAR version information file may contain details such as the name and version number of the AUTOSAR standard used, the publication date of the standard, and any relevant notes or comments regarding the software version. The file may also contain information about the target hardware and software environment, such as the microcontroller or microprocessor used, the operating system and software frameworks used, as well as any other relevant details about the hardware and software configuration.

[0097] The AUTOSAR version information file is an important part of the software development process because it provides critical information about the software version and its intended use. This information is essential to ensure the proper functioning of the software and to facilitate maintenance and updates of the software throughout its lifetime.

[0098] The term AUTOSAR target specification file can be understood as a document or set of information that provides detailed instructions and specifications for the development and implementation of an AUTOSAR (Automotive Open System Architecture) stack for a specific vehicle or vehicle system. This file contains the technical requirements and guidelines for developing the AUTOSAR stack, including the configuration and settings for the various components and modules that comprise the stack.

[0099] The AUTOSAR target specification file typically contains information such as: * The specific vehicle or vehicle system for which the AUTOSAR stack is being developed * The desired functional and performance characteristics of the stack * The specific components and modules that make up the stack, as well as their configuration and settings * The software and hardware requirements for the stack * Any specific tools or software required for the development and implementation of the stack

[0100] The AUTOSAR target specification file is an important document that serves as a guide for the development and implementation of the AUTOSAR stack. It is typically created and maintained by the vehicle manufacturer or the AUTOSAR stack supplier. The file can be in a standardized format, such as a PDF file or Excel spreadsheet, and can be updated and revised as needed to reflect changes in the requirements or specifications for the AUTOSAR stack.

[0101] The term "non-AUTOSAR target specification file" can be understood as a file containing specifications or requirements for a target system that does not conform to the AUTOSAR standard. This file may include details about the hardware, software, and / or network components of the target system, as well as any specific interfaces or protocols the system uses.

[0102] In the context of the patent application, the non-AUTOSAR target specification file is likely a file generated by an external source, such as a vehicle manufacturer or automotive component supplier. This file can be used to provide the information required to generate the AUTOSAR stack, such as the technical requirements for the target system, the hardware and software components used by the system, and any specific interfaces or protocols supported by the system.

[0103] The non-AUTOSAR target specification file can contain a variety of information, such as: * Details about the target system hardware, such as the processor, memory, and I / O interfaces. * Information about the software components of the target system, such as the operating system, middleware and application software. * Specifications for any network protocols or interfaces supported by the target system. * Any other relevant information required to generate the AUTOSAR stack for the target system.

[0104] It is important to note that the non-AUTOSAR target specification file is not a standardized file format and can be generated using a variety of different tools and techniques. Therefore, the file may be in a proprietary format, and specialized software or expertise may be required to generate and interpret the file.

[0105] Advantageously, according to another aspect of the invention, the use of various external data sources is possible, including ECU extract, DBC, System Extract, Excel, PDF, parameter definition, mapping sheet, properties, AUTOSAR version information, and / or non-AUTOSAR target specification files. This provides several advantages over the prior art: 1. Increased flexibility: The use of multiple external data sources allows for greater flexibility in configuring the AUTOSAR model. This contrasts with the state of the art, which relies on a single internal tool and manual configuration. 2. Improved efficiency: By automating the configuration process, the method according to any one of claims 1 to 3 eliminates the need for manual coding and reduces the time and effort required to generate the AUTOSAR model. This represents a significant improvement over the prior art, which is prone to quality issues and requires a significant amount of time and resources. 3. Increased accuracy: The use of parameter definition files, mapping sheets, and property files ensures that the AUTOSAR model is accurately configured and tailored to the OEM's specific requirements. This contrasts with the current state of the art, which relies on manual configuration and is prone to errors and inconsistencies. 4. Greater scalability: The ability to integrate data from multiple external sources enables greater scalability and adaptability in the AUTOSAR model. This is particularly beneficial in the automotive industry, where the complexity and diversity of vehicle systems continues to increase. 5. Improved compatibility: The use of AUTOSAR version information and non-AUTOSAR target specification files ensures compatibility with a broad range of systems and standards, including both AUTOSAR and non-AUTOSAR systems. This is a significant advantage over the current state of the art, which may not be compatible with all systems and standards.

[0106] According to another aspect of the invention, the step of creating the AUTOSAR stack comprises parsing the data from an external source, in particular the ECU extract file, the mapping sheet file, the parameter definition file and / or the properties file, and merging the parsed data into a unified file.

[0107] The term "parsing data from an external source" can be understood as the process of extracting and analyzing the information contained in the data received from an external source to prepare it for use in generating the AUTOSAR stack. This process involves identifying and extracting the relevant information from the data and organizing this information in a way that enables effective use by the data processing engine.

[0108] In particular, the parsing process may include the following steps: 1. Data extraction: The first step in parsing data from an external source is to extract the relevant information from the data. This may involve using various techniques, such as regular expressions or text parsing algorithms, to identify and extract the specific data elements required. 2. Data cleansing: After the relevant data has been extracted, it may be necessary to clean and format the data to ensure it is in a usable state. This may include removing any unnecessary or redundant data, inserting any missing values, and formatting the data in a consistent manner. 3. Data integration: After the data has been cleaned and formatted, it may be necessary to integrate data from multiple sources into a single, unified file. This may involve combining data from disparate sources, such as the ECU extract file, the figure sheet file, the parameter definition file, and the properties file, into a single file that can be used by the data processing engine. 4. Data validation: Before the data is used to generate the AUTOSAR stack, it may be necessary to validate the data to ensure it is correct and complete. This may involve checking the data against a set of predefined rules or constraints, or comparing the data to a known standard or reference.

[0109] The term “merging the parsed data into a unified file” can be understood as the process of combining and organizing data from different sources into a single file in such a way that the data is logically related and structured, and can be easily accessed and used by the software tool or system that will use it.

[0110] In this context, the term "parsed data" refers to the data that has been extracted and transformed into a format that can be easily processed and analyzed by the software tool or system. This can include data from various sources, such as the ECU extract file, the mapping sheet file, the parameter definition file, and / or the properties file.

[0111] A "unified file" refers to a single file containing all parsed data in a standardized and organized format that the software tool or system can easily access and use. This file can be in a specific format, such as XML or XLS, allowing for easy parsing and analysis of the data.

[0112] The process of merging the parsed data into a unified file can involve several steps, such as: 1. Data transformation: The data from the various sources may need to be transformed into a standardized format before it can be combined into a single file. This may include cleaning, normalizing, and structuring the data to ensure it is consistent and easy to analyze. 2. Data integration: The transformed data can then be integrated into a single file using a specific format and structure that allows for easy access and analysis. This may involve using a specific programming language or tool to generate the unified file. 3. Data validation: The merged data can then be validated to ensure it is correct and complete, and that it meets the technical requirements for the AUTOSAR stack. This may involve checking the data against a set of rules or constraints, or against a specific standard or specification.

[0113] Overall, the term "merging the parsed data into a unified file" can be understood as the process of combining and organizing data from different sources into a single file in such a way that the data is logically related and structured, and can be easily accessed and used by the software tool or system. This process may include data transformation, integration, and validation to ensure that the data meets the technical requirements for the AUTOSAR stack.

[0114] Advantageously, the method for generating the AUTOSAR stack according to the present claim enables the parsing of data from external sources, in particular from the ECU extract file, the mapping sheet file, the parameter definition file, and / or the properties file, and the merging of the parsed data into a unified file. This provides several technical advantages over the prior art: 1. Improved efficiency: By automating the process of creating the AUTOSAR stack, the need for manual coding and data entry is reduced, resulting in improved efficiency and productivity. 2. Increased accuracy: Parsing and merging data from external sources ensures that the generated AUTOSAR stack is accurate and consistent, reducing the likelihood of errors and inconsistencies that can occur with manual entry. 3. Flexibility: The ability to parse data from multiple sources allows greater flexibility in generating the AUTOSAR stack, allowing the inclusion of a wide range of data and configurations. 4. Improved quality: Using a consistent file for the generated AUTOSAR stack ensures that all relevant data and configurations are included, resulting in a higher quality end product.

[0115] Compared to the prior art, the present aspect of the invention provides a more efficient, accurate, and flexible method for generating the AUTOSAR stack with improved quality. The ability to parse data from multiple sources and merge it into a unified file is a significant advantage over the prior art, which may have relied on manual data entry and limitations regarding the data sources that could be used.

[0116] According to yet another aspect of the invention, the merging is performed by an Artop+ Excel Reader Blocker module, in particular by using general writer scripts.

[0117] The term “Artrop+ Excel Reader Blocker Module” can be understood as a software component designed to facilitate the merging of data from different sources into a unified file, particularly in the context of the process for flashing software, in particular an AUTOSAR stack for automated vehicle communication, to an ECU of a vehicle.

[0118] Specifically, the Artrop+ Excel Reader Blocker module is a software module capable of reading and parsing data from various sources, such as ECU extract files, figure sheet files, parameter definition files, and property files, and merging the parsed data into a unified file. The module is designed to use common Writer scripts to facilitate the merging process, ensuring that the data from the various sources is properly formatted and organized into a single, coherent file.

[0119] The Artrop+ Excel Reader Blocker module can be implemented as a software component integrated into the data processing engine responsible for generating the software, specifically the AUTOSAR stack for automated vehicle communication. The module can be written in a programming language such as C++, Java, or Python and can be designed to interact with other software components and tools used in the software flashing process.

[0120] In operation, the Artrop+ Excel Reader Blocker module can receive data from various sources, such as ECU extract files and figure sheet files, and parse the data to extract the relevant information. The module can then use common Writer scripts to merge the parsed data into a unified file, which can be in the form of an XML file and / or an XLSX file. The resulting file can then be used as input for generating the AUTOSAR stack.

[0121] The module is responsible for merging data from different sources into a unified file, which can then be used as input for the procedure for generating the AUTOSAR stack.

[0122] The term "general writer scripts" can be understood as a set of predefined and standardized scripts used to merge data from different sources into a unified file, particularly in the context of creating an AUTOSAR stack. These scripts are "general" in the sense that they are shared by multiple users and can be used to simplify the merge process for different applications and scenarios.

[0123] The general writer scripts are designed to work with various data formats, such as Excel files, XML files, and other file types that may be used in the context of the invention. These scripts are typically written in a programming language, such as Python or JavaScript, and are designed to be flexible and adaptable to different data sources and requirements.

[0124] The general writer scripts can include a variety of functions and operations, such as data cleansing, data transformation, data aggregation, and data validation, to ensure that the data is in a suitable format for merging and that the resulting unified file is accurate and consistent. The scripts can also include error handling and debugging mechanisms to address any issues that may arise during the merging process.

[0125] By using common writer scripts, this aspect of the invention provides a standardized and efficient approach to merging data from different sources, which can help reduce the complexity and variability of the merging process and improve the overall quality and consistency of the resulting AUTOSAR stack.

[0126] Advantageously, the use of an Artop+ Excel Reader Blocker module provides several technical advantages over the state of the art: 1. Improved efficiency: Using a dedicated module to read and block Excel files streamlines the process, reducing complexity and improving the efficiency of the procedure. 2. Increased accuracy: By using common writer scripts, the module ensures that the data is read and blocked accurately, reducing the likelihood of errors and improving the overall quality of the AUTOSAR model. 3. Increased flexibility: The use of a modular approach allows for greater flexibility in the process, with additional input sources and formats being able to be incorporated as needed without significantly impacting the overall process. 4. Reduced manual effort: By automating the reading and blocking of Excel files, the process reduces manual effort and improves the overall efficiency of the product development process. 5. Improved consistency: The use of common writer scripts ensures that data is read and blocked consistently, reducing variability and improving the overall quality of the AUTOSAR model. 6. Improved scalability: The modular approach of the process allows for easier scaling of the process to accommodate larger and more complex projects without significantly compromising overall efficiency.

[0127] In a further aspect of the invention, an XML file and / or an XLXS file is generated from the merged unified file, encapsulating the data specific to the technical requirements of the AUTOSAR stack.

[0128] The term "XML file" can be understood as a computer file that stores data in a format defined by the Extensible Markup Language (XML). The file consists of a series of elements, each represented by a tag, and contains data in a structured and self-describing manner.

[0129] In the context of the present invention, the XML file is generated from the merged unified file containing the data specific to the technical requirements of the AUTOSAR stack. The XML file encapsulates this data, providing a standardized and machine-readable representation of the information.

[0130] The XML file can contain a variety of elements and attributes, such as: * Document Type Declaration, which specifies the XML version used to create the file. * Root element, which contains the main content of the file and is typically named after the data type it contains (for example, "AUTOSAR_Stack"). * Subelements that contain specific data regarding the technical requirements for the AUTOSAR stack, such as parameter definitions, mapping information and other relevant details. * Attributes that provide additional information about the elements and their relationships.

[0131] The XML file can contain a variety of metadata, such as: * File format version information that specifies the version of the XML standard used to create the file. * Creation and modification dates that indicate when the file was created and last modified. * Author and owner information that identifies the person or organization responsible for creating and maintaining the file.

[0132] Overall, the XML file is a critical component of the present invention because it provides a standardized and machine-readable representation of the data specific to the technical requirements for the AUTOSAR stack. This enables efficient and accurate data processing and facilitates the inclusion of additional information and metadata as needed.

[0133] The term "XLS file" can be understood as a file format that encapsulates data specific to the technical requirements for the AUTOSAR stack in a compiled, compressed, and password-protected format. An XLS file is a ZIP archive containing one or more Excel workbooks, each of which can contain multiple worksheets, charts, and other elements. The XLS file format is based on the Open XML standard, which provides a flexible and extensible format for storing and exchanging data between different applications and systems.

[0134] The XLSX file format supports a range of features that enable it to encapsulate data specific to the technical requirements for the AUTOSAR stack, such as: * Support for multiple worksheets and charts, allowing you to organize complex data sets and present results in a clear and concise manner. * Support for formulas and functions, enabling the calculation of values ​​and the automation of processes. * Support for data validation and formatting, ensuring the accuracy and consistency of data entered into worksheets. * Support for password protection and encryption, providing secure access to the data contained in the Xlsx file.

[0135] In the context of the present invention, the XIsx file is generated from the merged unified file encapsulating the data specific to the technical requirements of the AUTOSAR stack, using a computer program or script specifically designed for this purpose. The XIsx file can then be used as input for the process of generating the AUTOSAR ECUC (Electronic Control Unit Configuration) file.

[0136] It should be noted that the term "XLS file" is intended to include all variants of the Open XML standard that can be used to encapsulate data specific to the technical requirements of the AUTOSAR stack, including, but not limited to, XLS, XLSM and XLTX files.

[0137] The term "merged unified file" can be understood as a comprehensive and integrated dataset that combines all the information and data required for the AUTOSAR automated vehicle communication stack, specifically tailored to the technical requirements of the vehicle's ECU. This file represents a consolidated and standardized format for the data, enabling seamless integration and processing by the data processing engine.

[0138] The merged unified file encompasses a wide range of data formats, including, but not limited to, ECU extract files, DBC files, SystemExtract files, Excel files, PDF files, parameter definition files, mapping sheet files, properties files, AUTOSAR version information files, AUTOSAR target specification files, and / or non-AUTOSAR target specification files. This comprehensive approach ensures that all critical information and data required for the AUTOSAR stack is efficiently captured and processed, eliminating any potential errors or inconsistencies.

[0139] Furthermore, the merged unified file is generated through a carefully designed and structured process that includes parsing the data received from various sources, such as the ECU extract file, the figure sheet file, the parameter definition file, and / or the properties file. This parsing process is performed using dedicated modules, such as the Artop+ Excel Reader Blocker module, which ensures that the data is accurately extracted and integrated into a single, unified file.

[0140] The resulting merged unified file is then further processed to generate an XML file and / or an XLSX file that encapsulates the data specific to the technical requirements of the AUTOSAR stack. This encapsulation process ensures that the data is securely contained and protected, preventing any unintentional changes or tampering that could compromise the integrity of the AUTOSAR stack.

[0141] In summary, the term "merged unified file" refers to a carefully crafted dataset containing all essential information and data required for the AUTOSAR automated vehicle communication stack, standardized and integrated into a single file for seamless processing by the data processing engine. This file is the culmination of a carefully structured process that combines and extracts data from various sources, ensuring the accuracy, completeness, and integrity of the data required for the AUTOSAR stack.

[0142] A technical advantage of this aspect of the invention over the prior art is that it provides a more efficient and streamlined method for generating the AUTOSAR stack. By using a unified file containing all required data, the method eliminates the need for manual coding and reduces the likelihood of errors and inconsistencies.

[0143] Another technical advantage of this aspect of the invention is that it provides greater flexibility and adaptability in the product development process. The unified file can be easily modified and updated to reflect changes in the technical requirements for the AUTOSAR stack, enabling more efficient iteration and testing of different design options.

[0144] According to another aspect of the invention, an AUTOSAR ECUC (Electronic Control Unit Configuration) file is generated from the XML file and / or the XIxs file to generate the AUTOSAR stack.

[0145] The term "AUTOSAR ECUC file" can be understood as a computer file containing the configuration information required to generate an AUTOSAR automated vehicle communication stack for a specific vehicle electronic control unit (ECU). The file is generated based on the technical requirements for the AUTOSAR stack, as described in the preceding claims, and encapsulates the data specific to those requirements in a standardized format.

[0146] In particular, the AUTOSAR ECUC file can consist of one or more of the following elements: * An XML (Extensible Markup Language) file that contains the configuration information for the AUTOSAR stack, including the technical requirements, the software components, and the interconnectivity between the components. * An XLXS (Extensible Markup Language with Syntax Highlighting) file that provides a human-readable representation of the configuration information, with syntax highlighting and indentation to make the file easier to understand and maintain.

[0147] The AUTOSAR ECUC file may also include other information, such as version numbers, software license information, and documentation, to provide a complete description of the AUTOSAR stack and its configuration.

[0148] The use of the term "AUTOSAR ECUC file" in the context of the patent application is intended to convey the idea that the file contains the configuration information required to generate the AUTOSAR automated vehicle communication stack for a specific ECU of a vehicle and that the file is in a standardized format that is widely used and recognized in the industry.

[0149] The term AUTOSAR stack can be understood as a collection of software components and their configurations that together provide a set of standardized interfaces and functionalities for vehicle communication and control. The AUTOSAR stack is designed to be flexible and adaptable to different vehicle and software environments and is typically used in vehicle electronic control units (ECUs) to facilitate communication and data exchange between different systems and components within the vehicle.

[0150] The AUTOSAR stack includes a range of software components, such as bus management, communication protocols, and application software, organized in a hierarchical structure. The stack is designed to be modular and extensible, allowing new software components and functionalities to be added as needed.

[0151] According to another aspect of the invention, a computer program comprises instructions which, when the computer program is executed by a computer, cause the computer to carry out the method according to any one of the preceding embodiments.

[0152] The term "computer program" can be understood as a set of instructions, instructions, or data stored on a computer-readable medium and executed by a computer to perform a specific task or set of tasks. The computer program may include one or more software modules, routines, or subroutines designed to perform specific functions or operations.

[0153] According to yet another aspect of the invention, a system for flashing software, in particular an AUTOSAR stack for automated vehicle communication, onto an ECU of a vehicle comprises: - means for receiving data from an external source, the data being specific to technical requirements for the AUTOSAR stack; - means, in particular a data processing engine, for generating the software, in particular the AUTOSAR stack for automated vehicle communication, based on the received data; - Means for sending the software to the ECU and for storing the software in the ECU.

[0154] The term "means for receiving data from an external source" can be understood as a component or module within the system that is responsible for receiving or collecting data from an external source specific to the technical requirements of the AUTOSAR stack. This external source can be a database, a file system, a network, or any other suitable data source.

[0155] The means for receiving data from an external source can be implemented using a variety of technologies and protocols, such as web services, application programming interfaces (APIs), or other data transfer protocols. The specific implementation details of these means are not critical to understanding the invention, as long as they are suitable for receiving data from an external source and providing it to the data processing engine for generating the software.

[0156] The term "means for receiving data from an external source" includes any suitable technology or device that can facilitate the transmission of data from an external source to the system. This may include, but is not limited to, a network interface, a data port, a storage device, or any other suitable component or device that can receive data from an external source.

[0157] In one embodiment, the means for receiving data from an external source may be implemented using a web service that receives data from a database or file system. The web service may be a RESTful web service, a SOAP-based web service, or any other suitable web service capable of receiving data from an external source.

[0158] In another embodiment, the means for receiving data from an external source may be implemented using an API that receives data from a software application or script. The API may be a web API, a desktop API, or any other suitable API capable of receiving data from an external source.

[0159] In yet another embodiment, the means for receiving data from an external source may be implemented by using a data transfer protocol, such as FTP, SFTP, or HTTP. The data transfer protocol may be used to transfer data from an external source to the system, and the means for receiving data from an external source may be implemented by using a software component or module that can receive data from the data transfer protocol.

[0160] The term “means” throughout the specification may be understood as referring to any device, component, or module capable of performing the functions and actions described in the embodiments of the specification.

[0161] The term "means, in particular a data processing engine, for generating the software" can be understood as referring to any device, component, or module capable of generating the software, such as a central processing unit (CPU), a graphics processing unit (GPU), or a field-programmable gate array (FPGA). This may include, but is not limited to, a software development kit (SDK), a compiler, or an interpreter.

[0162] The term “means for sending the software to the ECU and for storing the software in the ECU” can be understood as referring to any device, component or module suitable for sending the software and storing it in the ECU, such as a communication interface, a storage device or a software installation module.

[0163] The term “for generating the software” in this aspect of the invention can be understood as the process of generating or producing the AUTOSAR stack for automated vehicle communication based on the received data specific to the technical requirements of the AUTOSAR stack.

[0164] In particular, the term "to generate the software" may be understood to include the use of a data processing engine, which may be a software module, a hardware module, or a combination of both, to process the received data and generate the AUTOSAR stack. The data processing engine may be configured to perform the steps of parsing, formatting, and / or generating the AUTOSAR stack based on the received data and may be implemented using a variety of programming languages ​​and software development frameworks, such as Java, Python, C++, and / or the like.

[0165] The term "means for sending the software to the ECU" can be understood as a component or module responsible for transferring the generated software, in particular the AUTOSAR stack for automated vehicle communication, from the system to the vehicle's electronic control unit (ECU). This component or module can be implemented using a variety of technologies and protocols, such as a dedicated communication interface, a network interface, or a software interface.

[0166] In one embodiment, the means for transmitting the software to the ECU may comprise a wireless communication interface, such as a Bluetooth or Wi-Fi interface, capable of wirelessly transmitting the software to the ECU. The wireless communication interface may be connected to a wireless communication protocol, such as a Wi-Fi or Bluetooth protocol, that allows the software to be transmitted to the ECU via a wireless connection.

[0167] In another embodiment, the means for sending the software to the ECU may comprise a wired communication interface, such as a Universal Serial Bus (USB) or Ethernet interface, capable of transmitting the software to the ECU via a wired connection. The wired communication interface may be connected to a communication protocol, such as a USB or Ethernet protocol, that enables the software to be transmitted to the ECU via a wired connection.

[0168] In another embodiment, the means for sending the software to the ECU may comprise a software interface that enables the software to be transferred to the ECU via a software download. The software interface may be implemented using a variety of technologies, such as a web interface or a dedicated software download client.

[0169] The term "means for storing software in the ECU" can be understood as a component or module responsible for storing software, in particular the AUTOSAR stack for automated vehicle communication, in the vehicle's electronic control unit (ECU). This component or module can be implemented using a variety of technologies, such as flash memory, read-only memory (ROM), or programmable memory, such as random access memory (RAM).

[0170] The means for storing the software in the ECU may be configured to receive the software from the data processing engine and store the software in a specific location or locations within the ECU. The means for storing the software in the ECU may also be configured to manage the storage of the software, such as by providing error checking and correction, or by implementing security measures to prevent unauthorized access to the software.

[0171] Advantageously, the system provides a means for receiving data specific to the technical requirements of the AUTOSAR stack, enabling the generation of software tailored to the specific requirements of the vehicle. This contrasts with the prior art, which relies on manual coding and does not provide a means for receiving data specific to the AUTOSAR stack.

[0172] Advantageously, the system uses a data processing engine to generate the software, enabling automated generation of the AUTOSAR stack based on the received data. This eliminates the need for manual coding and improves the efficiency and accuracy of the software development process.

[0173] Advantageously, the system provides a means for sending the software to the ECU and storing the software in the ECU, allowing the software to be transferred and installed directly to the ECU without the need for manual intervention. This simplifies the software installation process and reduces the risk of errors or inconsistencies.

[0174] The term "computer-readable storage medium" can be understood as a medium that stores computer-executable instructions or data that can be read and executed by a computer. The medium can be any device or medium capable of storing data and accessible by a computer, such as a hard disk, solid-state drive, flash drive, RAM, ROM, CD, DVD, Blu-ray Disc, or a remote storage device accessible over a network.

[0175] Further advantages, features, and details of the invention will become apparent from the following description, in which embodiments of the invention are described in detail with reference to the drawings. In this context, the features mentioned in the claims and in the description may be essential to the invention individually or in any combination. It is shown: Fig. 1 A method, a computer program, a storage medium and a system according to embodiments of the invention, and Fig. 2: A method according to another embodiment of the invention.

[0176] Fig. 1 shows a schematic representation of method 100, computer program 20, data processing engine 30, storage medium 15, and system 10 according to embodiments of the invention. The method 100 for flashing software, in particular an AUTOSAR stack for automated vehicle communication, onto ECU 3, in particular of vehicle 1, according to an embodiment of the invention may comprise a first step 101, wherein data is received from an external source 40 via communication interface 41, wherein the data is specific to the technical requirements of the AUTOSAR stack. The method 100 comprises a further step 102 of generating the software, in particular the AUTOSAR stack for automated vehicle communication, based on the data received by a data processing engine.In the following step 103 of the method 100, the software is sent to the ECU via further communication interface 42 and stored in the ECU, in particular of the vehicle 1.

[0177] Fig.Figure 2 illustrates method 200 specifically implemented in software to generate an AUTOSAR stack for vehicle communication. In a first step 201, data is received as input from an external source, for example, a customer. This input may be in the form of an ECUextract file, a DBC file, an LDF file, a FIBEX file, a CAN matrix file, and / or an Excel file. In a next step 202, the input files may be converted into more suitable file formats. For example, from a DBC file to Arxml, or from an Excel file to an ECUextract file. In a next step 203, specific information is extracted from the input files and / or the converted input files. The specific information includes, for example, at least one of the following: • Property information containing additional settings, attributes or characteristics that affect the AUTOSAR model; • Parameter definitions that are crucial for the ECU configuration; • Mapping sheets to map and align data elements across different input files; • ECUextract information, which captures essential information about electronic control units (ECUs) in the system; • AUTOSAR version, which specifies the AUTOSAR version used; • Information about the target (AUTOSAR mode or non-AUTOSAR mode).

[0178] The extracted information is then merged and processed, for example, by an Artop+ Excel Reader Blocker, which uses common Writer scripts to merge the files and create a unified input structure. Additionally, an XML file and / or an XLSX file is generated from the merged unified file, encapsulating the data specific to the technical requirements of the AUTOSAR stack.

[0179] In the next step 204, AUTOSAR ECUC (Electronic Control Unit Configuration) file 205 is generated in a data processing engine 30 from the XML file and / or the XIxs file to establish the AUTOSAR stack.

[0180] Optionally, the AUTOSAR ECUC file 205 can be used to build 206 other suitable file formats 207, such as hex file 208, which can be further used in test environment 209 before being flashed to an ECU.

[0181] The same approach can be applied to or extended to diagnostic protocols. These diagnostic protocols can include UDS - ISO14229-1, OBD - ISO15031-5 over CAN and / or MOST bus.

Claims

[1] Method (100) for flashing software, in particular an AUTOSAR stack for automated vehicle communication, onto an ECU (3), in particular of a vehicle (1), comprising the following steps: - receiving (101) data from an external source (40), the data being specific to technical requirements for the AUTOSAR stack; - generating (102) the software, in particular the AUTOSAR stack for automated vehicle communication, based on the data received by a data processing engine (30); - Sending (103) the software to the ECU (3) and storing the software in the ECU (3). [2] The method (100) of claim 1, wherein the step of generating the AUTOSAR stack comprises processing a plurality of data formats of the received data into one, in particular a single, AUTOSAR-specific format via a predefined or definable script. [3] The method (100) of claim 2, wherein the script is based on Java. [4] The method (100) of any one of claims 1 to 3, wherein the data from the external source (40) comprises at least one of the following: ECU extract file, DBC file, SystemExtract file, Excel file, PDF file, parameter definition file, mapping sheet file, properties file, AUTOSAR version information file, AUTOSAR target specification file, and / or non-AUTOSAR target specification file. [5] Method (100) according to one of the preceding claims, wherein the step of generating the AUTOSAR stack comprises parsing the data from the external source (40), in particular the ECU extract file, the mapping sheet file, the parameter definition file and / or the properties file, and merging the parsed data into a unified file. [6] Method (100) according to claim 5, wherein the merging is carried out by an Artop+ Excel Reader Blocker module, in particular by using general writer scripts. [7] Method (100) according to claim 5 or 6, wherein an XML file and / or an XLXS file is / are generated from the merged unified file, encapsulating the data specific to the technical requirements of the AUTOSAR stack. [8] The method (100) of claim 7, wherein an AUTOSAR ECUC (Electronic Control Unit Configuration) file is generated from the XML file and / or the XLXS file to establish the AUTOSAR stack. [9] A computer program (20) comprising instructions which, when the computer program is executed by a computer, cause the computer to carry out the method (100) according to any one of the preceding claims. [10] System (10) for flashing software, in particular an AUTOSAR stack for automated vehicle communication, onto an ECU (3) of a vehicle (1), comprising the following steps: - means (41) for receiving data from an external source (40), the data being specific to technical requirements for the AUTOSAR stack; - means, in particular a data processing engine (30), for generating the software, in particular the AUTOSAR stack for automated vehicle communication, based on the received data; - means (42) for sending the software to the ECU (3) and storing the software in the ECU (3). [11] A computer-readable storage medium (15) comprising instructions which, when executed by a computer, cause the computer to perform the steps of the method of any one of claims 1 to 8.

Images