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 example embodiments of the present disclosure relate to automatic code generation using Interface Definition Language (IDL). [Background technology]

[0002] In the related art, an Interface Definition Language (also known as an IDL) is a description language that may be used to define data types and interfaces independently of the underlying operating system (OS) / programming language. In this regard, interfaces may be defined using IDL and translated into the underlying OS / programming language (e.g., C, C++, Java, etc.). This allows users to define data types / interfaces in a language-independent manner, enabling bridging between two different operating systems / programming languages. Summary of the Invention

[0003] Typically, related technologies cannot use dynamic memory allocation for the data types defined for IDL. This may be the case when IDL is used in applications involving safety-critical situations. For example, for applications in the automotive industry, sensors on vehicles may require a certain level of precision, or a certain number of data points may need to be collected to ensure that the application's operation is within safety standards. In this regard, if static data allocations (e.g., strings with a maximum size of 5 or arrays with a maximum size of 8) are defined, overflows may occur or data precision or data points may be erroneously truncated. On the other hand, if memory allocations are statically set high, they may be inefficient and consume too much memory.

[0004] Furthermore, the related art may not consider how to create constraints relevant to safety-critical situations. At best, the related art may consider how to validate an IDL file using a validation program against a predetermined set of rules, but the predetermined set of rules (which are low-level and specific) may not be clearly mappable to a safety standard that encompasses a higher-level and abstract set of constraints.

[0005] Therefore, there is a need for an IDL that can meet safety-critical conditions and safety standards.

[0006] According to one or more exemplary embodiments, an apparatus and method for automatic code generation using an Interface Definition Language (IDL) is provided. Specifically, the apparatus and method according to the 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 (e.g., 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 determining that the IDL file conforms to the low-level rules file.

[0007] Therefore, safety-critical scenarios requiring specific data precision / number of data points can be encompassed by using dynamic memory allocation for data types / interfaces in the IDL file. Additionally, more abstract rules (which may encompass safety criteria) can be defined in high-level rule files, allowing users to more easily map IDL files to conform to those rule sets.

[0008] According to an embodiment, a method for generating code can be provided, the method including 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 conforms to the low-level rules file, and generating code based on the IDL file based on determining that the IDL file conforms to the low-level rules file.

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

[0010] Converting the high-level rules file to a low-level rules file includes interpreting the high-level rules file using a machine learning model. The high-level rules file may include a safety criteria document. The low-level rules file may include at least one rule of an element or combination of elements that cannot be included in an IDL file. The low-level rules file may include at least one rule of a boundary that cannot be exceeded in an IDL file.

[0011] According to an embodiment, the method may further include sending a warning message based on determining that the IDL file does not comply with the lower level rules file.

[0012] Additional aspects will be set forth in part in the description that follows, and in part will be apparent from the description, or may be realized by practice of the presented embodiments of the present disclosure.

[0013] Features, aspects, and advantages of certain exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which like reference numerals refer to like elements. [Brief explanation of the drawings]

[0014] [Figure 1]FIG. 1 is a diagram of exemplary components of an apparatus according to an exemplary embodiment. [Figure 2] FIG. 2 is a block diagram illustrating an example of an example Interface Definition Language (IDL) file and a rule file in accordance with one or more example embodiments. [Figure 3] FIG. 3 is a block diagram illustrating an example system architecture for generating code based on an IDL file and a rules file in accordance with one or more exemplary embodiments. [Figure 4] FIG. 4 is a flowchart illustrating a method for generating code based on an IDL file and a rules file in accordance with one or more example embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0015] The following detailed description of exemplary embodiments refers to the accompanying drawings. The present disclosure provides illustration and description, but is not intended to be exhaustive or to limit one or more exemplary embodiments to the precise form disclosed. Modifications and variations are possible in light of the present disclosure or may be acquired from the practice of one or more exemplary embodiments. Moreover, 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, in the flowcharts and operational descriptions provided herein, it should be understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed concurrently (at least in part), and the order of one or more operations may be switched.

[0016] It will be apparent that exemplary embodiments of the systems and / or methods and / or non-transitory computer-readable storage media described herein may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not intended to limit one or more examples. Thus, the operation and behavior of the systems and / or methods and / or non-transitory 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 description herein.

[0017] Although particular combinations of features are recited in the claims and / or disclosed herein, these combinations are not intended to limit the disclosure of possible example embodiments. Indeed, many of these features can be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible example embodiments includes each dependent claim in combination with every other claim in the claim set.

[0018] No element, act, or instruction used herein should be construed as critical or required unless explicitly stated as such. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "a" or similar language is used. Also, as used herein, terms such as "has," "have," "having," "include," and "including" are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless otherwise specified. Furthermore, phrases such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

[0019] Apparatus and methods consistent with the concepts of the present invention provide a process for generating code using an Interface Definition Language (IDL). Specifically, apparatus and methods according to example 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 (e.g., safety standards), converting the high-level rules file to a low-level rules file (e.g., 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 determining that the IDL file conforms to the low-level rules file.

[0020] 1 is a diagram of example components of device 100. As shown in FIG. 1, device 100 may include a bus 110, a processor 120, a memory 130, a storage 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), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an 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, and / or optical storage) 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 a hard disk (e.g., a magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive. The input component 150 includes components that enable the device 100 to receive information via user input (e.g., a touchscreen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone). Additionally 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 an actuator). 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] Communications interface 170 includes transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that enable device 100 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communications interface 170 may enable device 100 to receive information from and / or provide information to other devices. For example, communications 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, etc.

[0024] Device 100 may perform one or more example processes described herein. According to one or more example embodiments, device 100 may perform these operations in response to processor 120 executing software instructions stored by a non-transitory computer-readable medium, such as memory 130 and / or storage component 140. Computer-readable medium is defined herein as a non-transitory storage device. Storage 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 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 component 140 may cause processor 120 to perform one or more processes described herein.

[0026] Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement one or more of the processes described herein. Thus, one or more exemplary embodiments described herein are not limited to any specific combination of hardware circuitry and software.

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

[0028] 2 is a block diagram illustrating example Interface Definition Language (IDL) files and rule files according to one or more exemplary embodiments. According to an embodiment, an IDL file 200, a high-level rule file 210, and a low-level rule file 220 may be provided.

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

[0030] Data types and interfaces implemented in IDL files may contain dynamically sized structures (e.g., to implement dynamic memory allocation), thus encompassing scenarios where a certain level of precision or data points is required (e.g., 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 (float32, float64), boolean, void, byte, string (fixed, dynamically sized, or dynamically sized with a maximum), void, dynamically sized array with bounded size N, fixed-sized array of size N, dynamically sized string with bounded size N, general multidimensional arrays, etc.

[0032] Below 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 dynamically sized arrays of maximum size 5, each of which is an array of signed 8-bit integers of size 3.

[0034] string(<=5)

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

[0035] string(<=5)[<=10] / / A dynamically sized array of max size 10 of a dynamically sized string of max size 5 bytes.

[0036] string(<=3)

[10] [<=5][4] / / A multidimensional (3D) array of size 10, whose elements are dynamically sized arrays of size 5, each of which is an array of size 4 made up of dynamically sized strings of size 3.

[0037] According to embodiments, a high-level rules file 210 may be provided. The high-level rules file 210 may define a set of rules in more abstract terms that cannot be easily interpreted by a validation program. For example, the high-level rules file 210 may be written in natural language (a language that can be easily interpreted by a human user). According to some embodiments, the high-level rules file 210 may be a list / array of rules written in natural language. In some examples, the high-level rules file may be a safety criteria file that may define, for example, unit conversions (e.g., miles per hour cannot be used and must be converted to kilometers per hour), the accuracy level required for a particular process within the 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 rules file 210 may be a text file. According to some embodiments, it may also 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 rules file 210 may be converted into a low-level rules file 220. The low-level rules file is easily interpreted by a validation program and may be in the form of programming code. According to an 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 rules file 210. The low-level rules file 220 may specify, for example, which elements are or are not allowed to be included in the IDL file, or bounds on values ​​within the IDL file (e.g., array size limits). It should be appreciated that other types of rules may be included depending on the particular implementation.

[0040] A validation program may be used to check the lower-level rules file 220 against the IDL file 200 to see if the IDL file 200 conforms to the lower-level rules file 220. It should be appreciated that, according to some embodiments, the validation program may include a component / module for converting the higher-level rules file 210 to the lower-level rules file 220, and the validation program may accept the higher-level rules file 210 as input along with the IDL file 200 and perform the conversion.

[0041] If the validation program determines that the IDL file 200 complies with the low-level rule file 220, a code generator may automatically generate code based on the IDL file (e.g., in a code language such as C, C++, etc.). On the other hand, if the validation program determines that the IDL file 200 does not comply with the low-level rule file 220, an error / warning message may be sent to the user.

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

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

[0044] FIG. 3 is a block diagram illustrating an example system architecture for generating code based on an IDL file and a rules file in accordance with one or more exemplary embodiments.

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

[0046] Components and modules that may be provided are a rule translator 310, a validation 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 some components may be combined (e.g., rule translator 310 and validation program 320 may be integrated into a single component).

[0047] Initially, an IDL file 301 may be provided. The IDL file 301 may be received by both the validation program 320 and the code generator 330. The code generator 330 may provide a request to the validation program 320 to validate the IDL file. The validation program 320 may proceed to get to request the lower-level rules file 303.

[0048] If the low-level rule file 303 has not yet been generated, the high-level rule file 302 is provided to the rule converter 310, which can convert the high-level rule file 302 into the low-level rule file 303 (e.g., using an LLM model). Alternatively, if the 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 validation program 320. The validation 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 IDL file 301 is determined to conform to the low-level rule file 303 based on the validation program 320, permission is given 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, a user may provide user feedback 306 based on the results of the validation. In some cases, user feedback 306 may be used to directly edit high-level rule files 302. In some cases, user feedback 306 may be used to directly edit low-level rule files 303. Furthermore, if rule translator 310 operates using an ML model / LLM, user feedback 306 may be used as training data to train / refine the operation of rule translator 310.

[0052] FIG. 4 is a flowchart diagram illustrating a method 400 for generating code based on an IDL file and a rules file in accordance with one or more example embodiments.

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

[0054] At operation S420, the high-level rules file may be converted into a lower-level rules file (e.g., using a rules converter such as rules converter 310 described above). According to an embodiment, the conversion may be performed using a machine learning (ML) model. The high-level rules file may include a safety criteria document. The lower-level rules file may include at least one rule of an element or combination of elements that cannot be included in an IDL file. Additionally, the lower-level rules file may include at least one rule of a boundary that cannot be exceeded in an IDL file.

[0055] In operation S430, it may be determined (e.g., using a validation program such as validation program 320 described above) whether the IDL file conforms to the lower level rule file.

[0056] In operation S440a, if S430 determines that it is "Yes," code is generated (eg, using a code generator such as code generator 330) based on the IDL file.

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

[0058] Based on the above, it can be seen that safety-critical scenarios requiring specific data precision / number of data points can be encompassed by using dynamic memory allocation for data types / interfaces in IDL files. Additionally, more abstract rules (which may encompass safety criteria) can be defined in high-level rule files, allowing users to more easily map IDL files to conform to those rule sets.

[0059] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the exemplary embodiment or embodiments to the precise forms disclosed. Modifications and variations are possible in light of the disclosure or may be acquired from practice of the exemplary embodiment or 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 components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium (or medium) having computer-readable program instructions for causing a processor to perform operations.

[0061] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. 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 disc read-only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or 3D structures in grooves having instructions recorded thereon, and any suitable combination of the above. Computer-readable storage medium, as used herein, should not be construed as being a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over a wire.

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

[0063] The computer-readable program code / instructions for carrying out operations may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk®, C++®, and procedural programming languages ​​such as the “C” programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, as a stand-alone software package, 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 a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In one or more exemplary embodiments, an electronic circuit including, for example, 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 the computer-readable program instructions to personalize the electronic circuit to perform an aspect or operation.

[0064] These computer-readable program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer-readable program instructions can also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that a computer-readable storage medium having instructions stored therein includes an article of manufacture containing instructions that implement aspects of the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0065] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to generate a computer-implemented process that executes on the computer, other programmable data processing apparatus, or other device a series of operational steps that are performed on the computer, other programmable data processing apparatus, or other device such that the instructions, executing on the computer, other programmable data processing apparatus, or other device, implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0066] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible exemplary embodiments of systems, methods, and computer-readable media according to one or more exemplary embodiments. In this regard, each block in the flowcharts or block diagrams may represent a microservice, module, segment, or portion of an instruction set, comprising one or more executable instructions for implementing the specified logical function(s). The methods, computer systems, and computer-readable media may include additional, fewer, different, or arranged differently than shown in the figures. In one or more alternative exemplary embodiments, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be executed concurrently or substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by special-purpose hardware-based systems that perform specified functions or acts or execute a combination of special-purpose 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 a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods does not limit one or more embodiments. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. receiving, by a code generator, an Interface Definition Language (IDL) file and a high-level rules file; converting the high-level rules file into a low-level rules file by the code generator; determining, by the code generator, whether the IDL file conforms to the low-level rules file; generating, by the code generator, code based on the IDL file based on determining that the IDL file conforms to the low-level rules file; A method for generating code, comprising:

2. The method of claim 1 , wherein the IDL file includes at least one data type or interface that has dynamic memory allocation.

3. The method of claim 1 , wherein converting the high-level rules file to the low-level rules file comprises interpreting the high-level rules file using a machine learning model.

4. The method of claim 1 , wherein the high-level rules file includes a safety standards document.

5. The method of claim 1 , wherein the low-level rules file includes at least one rule for an element or combination of elements that cannot be included in the IDL file.

6. The method of claim 1 , wherein the low-level rules file includes at least one rule of a boundary that cannot be exceeded in the IDL file.

7. The method of any one of claims 1 to 6, further comprising sending a warning message based on determining that the IDL file does not conform to the low-level rules file.

8. at least one memory storing computer-executable instructions; receiving an Interface Definition Language (IDL) file and a high-level rules file; converting the high-level rules file into a low-level rules file; determining whether the IDL file conforms to the low-level rules file; generating code based on the IDL file based on determining that the IDL file conforms to the low-level rules file; at least one processor configured to execute the computer-executable instructions for:

2. An apparatus for generating a code having the following structure:

9. 9. The apparatus of claim 8, wherein the IDL file includes at least one data type or interface that has dynamic memory allocation.

10. 9. The apparatus of claim 8, wherein the at least one processor is configured to execute the computer-executable instructions for interpreting the high-level rules file using a machine learning model to convert the high-level rules file to the low-level rules file.

11. The apparatus of claim 8 , wherein the high-level rules file includes a safety standards document.

12. The apparatus of claim 8 , wherein the low-level rules file includes at least one rule for an element or combination of elements that cannot be included in the IDL file.

13. 9. The apparatus of claim 8, wherein the low level rules file includes at least one rule of a boundary that cannot be exceeded in the IDL file.

14. 14. The apparatus of claim 8, wherein the at least one processor is configured to execute the computer-executable instructions for sending a warning message based on determining that the IDL file does not comply with the low-level rules file.

15. 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; generating code based on the IDL file based on determining that the IDL file conforms to the low-level rules file; A computer program for generating code that causes a processor to perform processes including:

16. 16. The computer program product of claim 15, wherein the IDL file includes at least one data type or interface that has dynamic memory allocation.

17. 16. The computer program product of claim 15, wherein converting the high-level rules file to the low-level rules file comprises interpreting the high-level rules file using a machine learning model.

18. The computer program product of claim 15 , wherein the high-level rules file includes a safety standards document.

19. 16. The computer program of claim 15, wherein the low-level rules file includes at least one rule for an element or combination of elements that cannot be included in the IDL file.

20. A computer program according to any one of claims 15 to 19, wherein the low level rules file contains at least one rule of a boundary that cannot be exceeded in the IDL file.

Images