# An Empirical Study of the Code Generation of Safety-Critical Software Using LLMs
## 6 Discussions
### Prompt Engineering for Code Generation of Safety-Critical Software
Basic software function and domain standard specification requirements are extracted from the software requirement document. Phase 2: Generalization. Due to the presence of numerous domain-specific terms in the description of basic software function requirements, LLMs have a weak understanding of such terms. Therefore, it is necessary to convert domain-specific terms into general language descriptions. Phase 3: Refine. The domain standard specification requirements in the requirement document are usually top-level requirements. Specific requirements related to code implementation need to be further refined, including code standards, program structure, safety and security, performance, and other constraints. Phase 4: Integration. The prompts from the previous three phases are integrated to form a specific and complete contextual prompt. This prompt can be directly provided to the LLMs. The final Prompt-FDC consists of three parts: part 1, the basic functional requirement part, mainly describes the overall framework, functional points, and input/output requirements of the software in a structured manner; part 2, the domain feature generalization part, describes the domain-specific functional points in a generalized manner, enabling the LLMs to understand them directly; part 3, the domain standard specification constraint part, extracts key constraints from the perspective of the domain industry standard, in cluding language constraints, code standard constraints, structural constraints, safety and security constraints, performance constraints, etc. Phase 5: Iteration. This phase is optional. For complex requirements, the LLMs may not be able to generate code that satisfies all requirements at once. Therefore, based on the review and analysis of the generated code, iterative reinforcement can be performed in terms of domain requirements, specification constraints, etc. After several iterations, we can obtain higher-quality software code that meets the requirements for practical engineering applications. The quality of code generation is heavily dependent on the skill and methods used to transform and generalize the requirements. We further standardize the requirements transformation process, shown in Figure 5. We break down the transformation process into 10 steps. Each step completes the extraction and standardization of a class of requirements. Each type of requirement is standardized into XML format. The final result is a standardized document in XML format for the FDC requirements. Adherence to this XML format for all requirements transformations ensures consistency for generalized requirements. The standardized XML template for generalized requirements is shown in Appendix D. Listing A8. The standardized XML generalized requirements of the NucRate algorithm are shown in Appendix D. Listing A9. Figure 5: Standardization of requirement transformation process. As shown in Table 5, compared to other existing prompt methods discussed in Section 2.3, the proposed Prompt-FDC in this paper presents the most comprehensive prompt framework. It covers the requirements of safety-critical software and introduces a method to progressively refine and generalize domain requirements, enabling a more thorough understanding of the domain requirements and generating higher-quality code.