System and method for automatic code generation using an interface definition language

Abstract

To provide a system, a device and a method for generating a code.SOLUTION: The method may include receiving an interface definition language (IDL) file and a high-level rules file, converting the high-level rules file to a low-level rules file, determining whether the IDL file complies with the low-level rules file, and generating, by a code generator, code based on the IDL file based on determining that the IDL file complies with the low-level rules file.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] Systems and methods consistent with exemplary embodiments of the present disclosure relate to automatic code generation using an Interface Definition Language (IDL).

Background Art

[0002] In the related art, an Interface Definition Language (also referred to as IDL) is a description language that may be used to define data types and interfaces without depending on a basic operating system (OS) / programming language. In this regard, an interface is defined using IDL and can be converted into a basic OS / programming language (e.g., C, C++ (registered trademark), Java (registered trademark), etc.). Thereby, a user can define data types / interfaces in a language-independent manner and can enable bridging between two different operating systems / programming languages.

Summary of the Invention

[0003] Typically, the related art cannot use dynamic memory allocation for defined data types for IDL. This may apply when IDL is used in applications involved in safety-critical situations. For example, for applications in the automotive industry, sensors on a vehicle may require a specific level of accuracy, or a specific number of data points need to be collected to ensure that the operation of the application is within safety standards. In this regard, if static data allocations (e.g., a string with a maximum size of 5 or an array with a maximum size of 8) are defined, there may be an overflow or incorrect truncation of data accuracy or data points. On the other hand, if the memory allocation is set statically high, it is inefficient and may consume too much memory.

[0004] Furthermore, the relevant technologies may not consider how to create restrictions related to safety-critical situations. At best, the relevant technologies may consider how to validate IDL files using a validation program against a given set of rules, but the given set of rules (which are specific at a low level) may not be clearly mapped to safety standards that encompass a set of restrictions that are more abstract at a higher level.

[0005] Therefore, an IDL (Information Development Log) is needed that can meet safety-critical conditions and safety standards.

[0006] According to one or more exemplary embodiments, apparatus and methods for automated code generation using an interface definition language (IDL) are provided. Specifically, apparatus and methods according to exemplary embodiments may include receiving an interface definition language (IDL) file (which may have at least one defined data / interface type with dynamic memory allocation) and a high-level rules file (such as safety standards), converting the high-level rules file to a low-level rules file (for example, using a machine learning (ML) model), determining whether the IDL file conforms to the low-level rules file, and generating code based on the IDL file based on the determination that the IDL file conforms to the low-level rules file.

[0007] Therefore, by using dynamic memory allocation for data types / interfaces within the IDL file, safety-critical scenarios requiring specific data precision / number of data points can be accommodated. In addition, more abstract rules (which may encompass safety standards) can be defined in higher-level rule files, making it easier for users to map the IDL file to conform to those rule sets.

[0008] According to one embodiment, a method for generating code can be provided, which includes receiving an interface definition language (IDL) file and a high-level rule file, converting the high-level rule file to a low-level rule file, determining whether the IDL file conforms to the low-level rule file, and generating code based on the IDL file based on the determination that the IDL file conforms to the low-level rule file.

[0009] According to one embodiment, the IDL file may include at least one data type or interface having dynamic memory allocation.

[0010] Converting a high-level rule file to a low-level rule file involves interpreting the high-level rule file using a machine learning model. A high-level rule file may include safety standard documents. A low-level rule file may contain at least one rule of an element or combination of elements that cannot be included in an IDL file. A low-level rule file may contain at least one rule of a boundary that cannot be exceeded in an IDL file.

[0011] According to one embodiment, the method may further include sending a warning message based on the determination that the IDL file does not conform to a lower-level rules file.

[0012] Additional embodiments are partially described in the following description, partially evident from the description, or may be realized by implementing the embodiments presented in this disclosure.

[0013] Features, aspects, and advantages of certain exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, where similar reference numbers indicate similar elements. [Brief explanation of the drawing]

[0014] [Figure 1]Figure 1 shows exemplary components of an apparatus according to an exemplary embodiment. [Figure 2] Figure 2 is a block diagram showing examples of exemplary Interface Definition Language (IDL) files and rule files in one or more exemplary embodiments. [Figure 3] Figure 3 is a block diagram showing an example system architecture for generating code based on IDL files and rule files according to one or more exemplary embodiments. [Figure 4] Figure 4 is a flowchart showing a method for generating code based on an IDL file and a rules file according to one or more exemplary embodiments. [Modes for carrying out the invention]

[0015] A detailed description of the following exemplary embodiments is provided with reference to the accompanying drawings. This disclosure provides examples and descriptions, but is not intended to be exhaustive or to limit one or more exemplary embodiments to the exact form disclosed. Modifications and alterations are possible in light of this disclosure or can be obtained from the practice of one or more exemplary embodiments. Furthermore, one or more features or components of one exemplary embodiment may be incorporated into or combined with another exemplary embodiment (or one or more features of another exemplary embodiment). Furthermore, it should be understood that in the flowcharts and descriptions of operations provided herein, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least partially), and the order of one or more operations may be changed.

[0016] It will be apparent that exemplary embodiments of the systems and / or methods and / or non-temporary computer-readable storage media described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to one or more embodiments. Accordingly, the operation and behavior of the systems and / or methods and / or non-temporary computer-readable storage media are described herein without reference to specific software code. It should be understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

[0017] Certain combinations of features are described in the claims and / or disclosed herein, but these combinations are not intended to limit the disclosure of possible exemplary embodiments. In fact, many of these features can be combined in ways not specifically described in the claims and / or disclosed herein. Each dependent claim listed below may depend directly on only one claim, but the disclosure of possible exemplary embodiments includes each dependent claim in combination with all other claims in the set of claims.

[0018] Any elements, actions, or instructions used herein should not be construed as important or essential unless expressly stated otherwise. Furthermore, where used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more.” When only one item is intended, the term “one” or similar language is used. Also, where used herein, terms such as “has,” “have,” “having,” “include,” and “including” are intended to be open-ended terms. Additionally, the phrase “based on” should mean “at least partially based on” unless otherwise specified. Furthermore, expressions such as “at least one of [A] and [B]” or “at least one of [A] or [B]” should be understood as including only A, only B, or both A and B.

[0019] Apparatus and methods consistent with the concept of the present invention provide a process for generating code using an interface definition language (IDL). Specifically, apparatus and methods according to exemplary embodiments may include receiving an interface definition language (IDL) file (which may have at least one defined data / interface type with dynamic memory allocation) and a high-level rules file (such as safety standards), converting the high-level rules file to a low-level rules file (for example, using a machine learning (ML) model), determining whether the IDL file conforms to the low-level rules file, and generating code based on the IDL file based on the determination that the IDL file conforms to the low-level rules file.

[0020] Figure 1 is a diagram of exemplary components of the device 100. As shown in Figure 1, the device 100 may include a bus 110, a processor 120, a memory 130, a storage device component 140, an input component 150, an output component 160, and a communication interface 170.

[0021] Bus 110 includes components that enable communication between components of device 100. Processor 120 can be implemented in hardware, firmware, or a combination of hardware and software. Processor 120 may be a central processing unit (CPU), graphics processing unit (GPU), acceleration unit (APU), microprocessor, microcontroller, digital signal processor (DSP), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), or another type of processing component. In one or more embodiments, processor 120 includes one or more processors that are programmable to perform functions. Memory 130 includes random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic storage device, and / or optical storage device) that stores information and / or instructions used by processor 120.

[0022] The storage component 140 stores information and / or software related to the operation and use of the device 100. For example, the storage component 140 may include, along with a corresponding drive, a hard disk (e.g., magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disc (CD)®, a digital versatile disc (DVD)®, a floppy disk, a cartridge, magnetic tape, and / or another type of non-temporary computer-readable media. The input component 150 includes components that enable the device 100 to receive information via user input (e.g., a touchscreen display, keyboard, keypad, mouse, buttons, switches, and / or microphone). In addition, or alternatively, the input component 150 may include sensors for sensing information (e.g., a Global Positioning System (GPS) component, an accelerometer, a gyroscope, and / or actuators). The output component 160 includes components that provide output information from the device 100 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

[0023] The communication interface 170 includes transceiver-like components (e.g., transceivers and / or separate receivers and transmitters) that enable the device 100 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 170 may also enable the device 100 to receive information from and / or provide information to other devices. For example, the communication interface 170 may include, but is not limited to, an Ethernet® interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a Universal Serial Bus (USB) interface, a Wi-Fi® interface, a cellular network interface, and the like.

[0024] Device 100 may execute one or more exemplary processes described herein. According to one or more exemplary embodiments, device 100 may execute these processes in response to processor 120 executing software instructions stored by a non - transient computer - readable medium such as memory 130 and / or storage device component 140. The computer - readable medium is defined herein as a non - transient storage device. The storage device includes memory space within a single physical storage device or memory space distributed across multiple physical storage devices.

[0025] The software instructions may be read into memory 130 and / or storage device component 140 from another computer - readable medium or from another device via communication interface 170. When executed, the software instructions stored in memory 130 and / or storage device component 140 may cause processor 120 to execute one or more processes described herein.

[0026] In addition or alternatively, a hard - wired circuit may be used instead of or in combination with software instructions to execute one or more processes described herein. Accordingly, one or more exemplary embodiments described herein are not limited to any particular combination of hardware circuitry and software.

[0027] The number and arrangement of the components shown in FIG. 1 are provided as an example. In practice, device 100 may include additional components, fewer components, different components, or components arranged differently than those shown in FIG. 1. In addition or alternatively, a set of components of device 100 (e.g., one or more components) may perform one or more functions described as being performed by another set of components of device 100.

[0028] Figure 2 is a block diagram showing examples of interface definition language (IDL) files and rule files according to one or more exemplary embodiments. According to the embodiments, an IDL file 200, a high-level rule file 210, and a low-level rule file 220 can be provided.

[0029] According to one embodiment, an IDL file 200 may be provided and used to define data types and interfaces based on a predetermined syntax. According to another embodiment, the IDL file 200 may have a corresponding header file, which may specify all APIs defined in the IDL file. The IDL file may be in an XML-like format, but is not limited to XML.

[0030] Data types and interfaces implemented in an IDL file can include structures with dynamic sizing (for example, to implement dynamic memory allocation). Therefore, it can accommodate scenarios that require a specific level of precision or data points (such as safety-critical scenarios) while ensuring minimal memory consumption and avoiding overflows.

[0031] Data types include, but are not limited to, fixed-width integers (int8, uint8, int16, uint16, int32, uint32, int64, uint64), fixed-width floating-point numbers (float32, float64), booleans, void, bytes, strings (fixed, dynamic, or dynamic with a maximum size), void, arrays with dynamic size and bounding size N, fixed-size arrays of size N, strings with dynamic size and bounding size N, and general multidimensional arrays.

[0032] The following is an example of the syntax used to define a dynamically sized structure.

[0033] int8

[10] [<=5][3] / / A multidimensional (3D) array of size 10, whose elements are arrays of signed 8-bit integers of size 3, and which are arrays of dynamic size up to size 5.

[0034] string(<=5)

[10] / / A fixed-size array of size 10 containing strings of dynamic size with a maximum size of 5 bytes.

[0035] string(<=5)[<=10] / / An array of dynamically sized strings, with a maximum size of 5 bytes and a maximum size of 10 bytes.

[0036] string(<=3)

[10] [<=5][4] / / A multidimensional (3D) array of size 10, whose elements are arrays of size 4, composed of dynamically sized strings with a maximum size of 3, and arrays of size 5, which in turn are dynamically sized arrays.

[0037] According to the embodiments, a high-level rule file 210 can be provided. The high-level rule file 210 can define a set of rules in more abstract terms that are not easily interpreted by a verification program. For example, the high-level rule file 210 may be written in natural language (a language that can be easily interpreted by human users). According to some embodiments, the high-level rule file 210 may be a list / array of rules written in natural language. In some examples, the high-level rule file may be a safety standard file that can define, for example, unit conversions (e.g., miles per hour cannot be used and must be converted to kilometers per hour), the required level of precision for a particular process in an application (e.g., at least 10 data points must be collected from an accelerometer sensor for a sensor interface), and other interactions that must be included (e.g., a brake sensor interface for a vehicle must collect both timing and braking force data).

[0038] According to some embodiments, the format of the high-level rule file 210 may be a text file. According to some embodiments, it may be an image such as a PDF or a scanned document. In such cases, OCR may be used to convert the document into computer-readable text.

[0039] The high-level rule file 210 can be converted into a low-level rule file 220. The low-level rule file can be easily interpreted by a validation program and may be in the form of programming code. According to the embodiment, the conversion may be performed using a machine learning model (e.g., a large-scale language model: LLM, etc.) to interpret the high-level rule file 210. The low-level rule file 220 can specify, for example, which elements are allowed or not allowed to be included in the IDL file, or the boundaries of values ​​within the IDL file (e.g., array size limits). Please understand that other types of rules may be included depending on the specific implementation.

[0040] A verification program may be used to check the IDL file 200 against a lower-level rule file 220 to see if the IDL file 200 conforms to the lower-level rule file 220. According to some embodiments, the verification program may include components / modules for converting a high-level rule file 210 to a lower-level rule file 220, and it should be understood that the verification program can accept the high-level rule file 210 as input along with the IDL file 200 and perform the conversion.

[0041] If the verification program determines that IDL file 200 conforms to the lower-level rules file 220, the code generator may automatically generate code based on the IDL file (for example, in a coding language such as C or C++). On the other hand, if the verification program determines that IDL file 200 does not conform to the lower-level rules file 220, an error / warning message may be sent to the user.

[0042] According to some embodiments, the user can provide feedback while testing the application after the code has been generated based on the IDL file 200. For example, even if a validation program determines that the IDL file conforms to a lower-level rule file 220, the user can determine that the IDL file 200 does not conform. Therefore, the user can choose to provide feedback to the system on how to adjust the rules, which could be either a lower-level rule file 220 (if the user can read and understand the lower-level rules) or a higher-level rule file 210 (if the higher-level rules did not accurately reflect the safety standards in the first place). According to some embodiments, the feedback can be used as training data to improve the ML model used to convert the higher-level rule file 210 to the lower-level rule file 220.

[0043] According to some embodiments, the conversion from a high-level rule file 210 to a low-level rule file 220 does not need to be performed every time code is generated. For example, if the same high-level rule that has been previously converted to a low-level rule file 220 is used again, the converted low-level rule file 220 may already be cached, and validation can be performed immediately using the cached low-level rule file after the updated IDL file 200 is received.

[0044] Figure 3 is a block diagram showing an example system architecture for generating code based on IDL files and rule files according to one or more exemplary embodiments.

[0045] The files / data that may be provided are the IDL file 301, the high-level rule file 302, the low-level rule file 303 (which may correspond to the respective IDL file 200, high-level rule file 210, and low-level rule file 220 mentioned above), and user feedback 306. The files / data that may be generated are the compiled code 304 and error / warning messages 305.

[0046] The components and modules that may be provided are a rule converter 310, a verification program 320, and a code generator 330. Although the components and modules are illustrated as separate elements in Figure 3, it should be understood that several components may be combined (for example, the rule converter 310 and the verification program 320 can be integrated into a single component).

[0047] First, an IDL file 301 may be provided. The IDL file 301 may be received by both the verification program 320 and the code generator 330. The code generator 330 may provide the verification program 320 with a request to verify the IDL file. The verification program 320 may then proceed to retrieve a lower-level rules file 303.

[0048] If a low-level rule file 303 has not yet been generated, a high-level rule file 302 is provided to the rule converter 310, which can convert the high-level rule file 302 to a low-level rule file 303 (for example, using an LLM model). Alternatively, if a low-level rule file 303 has already been generated and a new high-level rule file 302 has not been provided, a cached copy can be provided to the verifier program 320. The verifier program 320 can then check whether the IDL file 301 conforms to the low-level rule file 303 based on the low-level rule file 303.

[0049] If the verification program 320 determines that the IDL file 301 conforms to the lower-level rules file 303, permission is granted to proceed to the code generator 330 to generate compiled code 304 based on the IDL file 301.

[0050] If the IDL file 301 is determined to be non-compliant with the lower-level rule file 303 based on the validation program 320, a warning / error message 305 is generated and returned to the user. For example, the warning / error message 305 lists which rules were not complied with.

[0051] According to some embodiments, the user can provide user feedback 306 based on the validation results. In some cases, the user feedback 306 may be used to directly edit the high-level rule file 302. In some cases, the user feedback 306 may be used to directly edit the low-level rule file 303. Furthermore, if the rule converter 310 operates using an ML model / LLM, the user feedback 306 can be used as training data to train / refine the operation of the rule converter 310.

[0052] Figure 4 is a flowchart illustrating a method 400 for generating code based on IDL files and rule files according to one or more exemplary embodiments.

[0053] In operation S410, an IDL file and a high-level rule file may be received. According to the embodiment, the IDL file may include at least one data type or interface having dynamic memory allocation.

[0054] In operation S420, a high-level rule file can be converted to a low-level rule file (for example, using a rule converter such as the rule converter 310 described above). Depending on the embodiment, the conversion may be performed using a machine learning (ML) model. The high-level rule file may include safety standard documents. The low-level rule file may include at least one rule of an element or combination of elements that cannot be included in the IDL file. Furthermore, the low-level rule file may include at least one rule of a boundary that cannot be exceeded in the IDL file.

[0055] In operation S430, it is possible to determine whether the IDL file conforms to a lower-level rule file (for example, using a verification program such as the verification program 320 mentioned above).

[0056] In operation S440a, if S430 is determined to be "Yes", code is generated based on the IDL file (for example, using a code generator such as code generator 330).

[0057] In operation S440b, if S430 is determined to be "No", an error / warning message is generated and returned to the user.

[0058] Based on the above, it can be understood that by using dynamic memory allocation for data types / interfaces within the IDL file, safety-critical scenarios requiring specific data precision / number of data points can be accommodated. In addition, more abstract rules (which may encompass safety standards) can be defined in higher-level rule files, making it easier for users to map the IDL file to conform to those rule sets.

[0059] The foregoing disclosure provides examples and explanations, but is not intended to be exhaustive or to limit one or more exemplary embodiments to the exact forms disclosed. Modifications and variations may be possible in light of this disclosure or may be derived from the practice of one or more exemplary embodiments.

[0060] One or more exemplary embodiments may relate to a system, method, and / or computer-readable medium at any possible level of technical detail of integration. Furthermore, one or more of the above-described components may be implemented as instructions stored in a computer-readable medium and executable by at least one processor (and / or include at least one processor). The computer-readable medium may include a computer-readable non-temporary storage medium (or medium) having computer-readable program instructions for causing a processor to perform an operation.

[0061] A computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution device. A computer-readable storage medium may be, but is not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk® read-only memory (CD-ROM), digital general-purpose disk (DVD)®, memory stick®, floppy disk, mechanically encoded devices such as punch cards or three-dimensional structures in grooves having instructions recorded thereon, and any suitable combination thereof. Computer-readable storage media, as used herein, should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted through wires.

[0062] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing unit, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing unit receives computer-readable program instructions from the network and transfers them to be stored in a computer-readable storage medium within each computing / processing unit.

[0063] The computer-readable program code / instructions for performing an operation may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk® and C++®, and procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions can run as a standalone software package entirely on the user's computer, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or the connection may be to an external computer (for example, via the Internet using an Internet Service Provider). In one or more exemplary embodiments, for example, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions by utilizing state information of computer-readable program instructions to personalize the electronic circuit in order to perform an action or operation.

[0064] These computer-readable program instructions are provided to the processor of a general-purpose computer, a dedicated computer, or other programmable data processing device so that instructions executed via the processor of the computer or other programmable data processing device can generate a machine that creates means for implementing functions / operations specified in blocks or blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct computers, programmable data processing devices, and / or other devices to function in a particular way, and as a result, a computer-readable storage medium having instructions stored therein includes a product containing instructions that implements modes of functions / operations specified in blocks or blocks of a flowchart and / or block diagram.

[0065] Computer-readable program instructions can also be loaded onto a computer, other programmable data processing device, or other device to cause a set of operational steps executed on the computer, other programmable device, or other device to generate a computer implementation process executed on the computer, other programmable device, or other device, so that instructions executed on the computer, other programmable data processing device, or other device implement a function / operation specified in a flowchart and / or block diagram block or block.

[0066] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible exemplary embodiments of a system, method, and computer-readable medium by one or more exemplary embodiments. In this regard, each block in a flowchart or block diagram may represent a microservice, module, segment, or part of an instruction, comprising one or more executable instructions for implementing a specified logical function. A method, computer system, and computer-readable medium may include additional blocks, fewer blocks, different blocks, or blocks arranged differently from those shown in the figures. In one or more alternative exemplary embodiments, the functions described in the blocks may occur out of order than shown in the figures. For example, two blocks shown consecutively may actually be executed simultaneously or substantially simultaneously, or the blocks may be executed in reverse order depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, may be implemented by a dedicated hardware-based system that performs a particular function or action, or a combination of dedicated hardware and computer instructions.

[0067] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to one or more embodiments. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it is understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

Claims

1. The code generator receives a rule file written in natural language, which includes an Interface Definition Language (IDL) file and safety standard documents. The code generation device converts the rule file, which includes the safety standards document and is written in natural language, into a rule file in the form of programming code. The code generation device determines whether the IDL file conforms to the rule file in the form of programming code, Based on the determination that the IDL file conforms to the rule file in the form of programming code, the code generator generates code based on the IDL file. A method for generating code, including [this].

2. The method according to claim 1, wherein the IDL file includes at least one data type or interface having a dynamic memory allocation.

3. The method according to claim 1, wherein converting the rule file, which includes the safety standard document and is written in natural language, into a rule file in the form of programming code comprises interpreting the rule file, which includes the safety standard document and is written in natural language, using a machine learning model.

4. The method according to claim 1, wherein the rules file, which includes the aforementioned safety standards document and is written in natural language, includes the safety standards document.

5. The method according to claim 1, wherein the rule file in the form of programming code includes at least one rule of an element or combination of elements that cannot be included in the IDL file.

6. The method according to claim 1, wherein the rule file in the form of programming code includes at least one rule for a boundary that cannot be exceeded in the IDL file.

7. The method according to any one of claims 1 to 6, further comprising sending a warning message based on the determination that the IDL file does not conform to the rules file in the form of programming code.

8. At least one memory for storing computer-executable instructions, It receives a rules file written in natural language, which includes an Interface Definition Language (IDL) file and safety standard documents. Convert the rule file, which includes the aforementioned safety standards document and is written in natural language, into a rule file in the form of programming code. Determine whether the IDL file conforms to the rules file in the form of programming code. Based on the determination that the IDL file conforms to the rules file in the form of programming code, code is generated based on the IDL file. At least one processor configured to execute the computer-executable instructions for the purpose of, A device that generates code having the following properties.

9. The apparatus according to claim 8, wherein the IDL file includes at least one data type or interface having a dynamic memory allocation.

10. The apparatus according to claim 8, wherein the at least one processor is configured to interpret the rule file, which includes the safety standard document and is written in natural language, using a machine learning model, and to execute the computer-executable instructions for converting the rule file, which includes the safety standard document and is written in natural language, into a rule file in the form of programming code.

11. The apparatus according to claim 8, wherein the rules file, which includes the aforementioned safety standards document and is written in natural language, includes the safety standards document.

12. The apparatus according to claim 8, wherein the rule file in the form of programming code includes at least one rule of an element or combination of elements that cannot be included in the IDL file.

13. The apparatus according to claim 8, wherein the rule file in the form of programming code includes at least one rule for a boundary that cannot be exceeded in the IDL file.

14. The apparatus according to any one of claims 8 to 13, wherein the at least one processor is configured to execute the computer-executable instruction for sending a warning message based on the determination that the IDL file does not conform to a rules file in the form of programming code.

15. Receiving a rules file written in natural language, which includes an Interface Definition Language (IDL) file and safety standard documents, Converting the aforementioned safety standards document and rule file written in natural language into a rule file in the form of programming code, Determining whether the IDL file conforms to the rules file in the form of programming code, Based on the determination that the IDL file conforms to the rules file in the form of programming code, code is generated based on the IDL file. A computer program that generates code, which causes a processor to perform a process that includes [a specific type of operation].

16. The computer program according to claim 15, wherein the IDL file includes at least one data type or interface having a dynamic memory allocation.

17. The computer program according to claim 15, wherein converting the rule file, which includes the safety standard document and is written in natural language, into a rule file in the form of programming code, includes interpreting the rule file, which includes the safety standard document and is written in natural language, using a machine learning model.

18. The computer program according to claim 15, wherein the rules file, which includes the aforementioned safety standards document and is written in natural language, includes the safety standards document.

19. The computer program according to claim 15, wherein the rule file in the form of programming code includes at least one rule of an element or combination of elements that cannot be included in the IDL file.

20. The computer program according to any one of claims 15 to 19, wherein the rule file in the form of programming code includes at least one rule for a boundary that cannot be exceeded in the IDL file.

Images