Automatic Generation of PLC Control Code from Natural Language Requirement Specifications

Control program development in manufacturing has traditionally followed two main approaches: heuristic methods and formal methods. Both have been used extensively in industry and academia. Each offers specific advantages but also presents important limitations. To better understand the motivations behind our proposed AI-based system, this section reviews the key principles and challenges of both methods. First, we describe the heuristic approach, which is based on the expert’s manual experience. Then, we present formal methods, which use mathematical modeling to ensure system correctness.

2.1 Heuristic methods

Heuristic methods refer to the traditional way of designing control programs based on the personal knowledge, intuition, and experience of the engineer. This approach does not rely on formal models or systematic reasoning. Instead, the expert interprets the system requirements and translates them into control logic manually. Heuristic methods are widely used in industrial environments because they are flexible and easy to apply in simple systems. They allow engineers to design solutions quickly when the system is small and well understood. However, as system complexity increases, relying only on intuition becomes more difficult and less reliable.

While heuristic methods are common in industrial settings, the process they follow is manual and iterative. It begins with the expert writing an informal requirement specification that describes the expected behavior of the system. Based on this description, the expert manually creates a control program using their experience and domain knowledge. The program is then tested through simulation to check whether it behaves as intended. If the simulation reveals errors, the expert revises the program and repeats the test. This cycle continues until the logic is considered correct. Finally, the validated program is transferred to the programmable logic controller (PLC), which is often referred to as the brain of the manufacturing system. The PLC executes the control logic using standard programming languages defined by the IEC 61131-3 standard [16]. These include three graphical languages, Ladder Diagram (LD), Function Block Diagram (FBD), and Sequential Function Chart (SFC) and two textual languages Instruction List (IL) and Structured Text (ST). The overall heuristic workflow is illustrated in Figure 1.

image003.png

Figure 1. Workflow for control program development using heuristic methods

Heuristic methods are often used in universities and in small systems where the number of components is limited. In these simple cases, the expert can understand the requirement easily and write the control logic without difficulty. However, when the system becomes more complex, this method reaches its limits. It becomes harder to understand the interactions between components. Writing and testing the program takes more time. Since the process is manual, it is also more likely to include errors. Another limitation is related to maintenance. When changes are needed, it is often difficult to modify the program correctly, especially if it was written by someone else. In addition, learning to program in this way takes time and requires experience. For these reasons, heuristic methods are not suitable for large and dynamic systems that need reliability, consistency, and fast updates. This limitation has led to the development of formal methods, which aim to improve control program design through structured modeling and verification.

2.2 Formal methods

Formal methods offer a clear and structured approach for designing control programs. They rely on mathematical models to precisely describe how a system should behave and the rules it must follow [17, 18]. These methods are particularly valuable when safety, correctness, and reliability are important. Unlike heuristic methods, which depend mainly on human experience, formal methods allow the control logic to be verified and tested before the system is implemented. This verification step helps reduce errors during operation and makes the system easier to maintain and update later.

The process begins with a requirement specification, a clear description of what the system is expected to achieve. From this specification, an expert identifies the system components and defines two important types of constraints. Liveness constraints specify outcomes that the system must eventually achieve, such as moving a robotic arm to a precise location. Safety constraints define conditions that the system must avoid, such as activating two conflicting actions simultaneously [17, 18]. Using this information, two formal models are created. The first model, called the behavior model, describes step-by-step how the system operates. The second model, called the constraint model, clearly defines all the liveness and safety constraints. Together, these models provide a complete and precise description of the system’s allowed behaviors.

These models are often represented using formal tools such as finite automata, Petri nets, or GRAFCET diagrams. From these representations, controllers are developed in two main stages. First, local controllers are created for each component individually, ensuring they comply with their own specific constraints. Next, the local controllers are combined with global constraints to form distributed controllers, which coordinate the entire system. This combination process is known as controller synthesis and is commonly performed using Supervisory Control Theory or similar techniques. The result is a robust control strategy that only allows the system to behave in ways permitted by the original specification.

After creating these distributed controllers, they undergo a verification step to confirm that all requirements are met under every possible scenario. For complex systems that involve timing or multiple processes running simultaneously, model checking is performed. Model checking uses specialized tools such as UPPAAL or SUPREMICA to systematically explore the system’s state space and detect any problems, including potential deadlocks or violations of safety and liveness constraints. If any issues are found, the constraints or models are revised, and the synthesis and verification steps are repeated until the controllers satisfy all requirements fully.

Once the verification step is successfully completed, the validated controllers are translated into Grafcet diagrams or other suitable programming formats. These diagrams can be directly deployed onto programmable logic controllers. This step ensures that the system operates exactly as designed, minimizing the need for further debugging during commissioning. The complete workflow for developing control programs using formal methods from initial specification through to final PLC implementation is shown in Figure 2.

image004.png

Figure 2. Workflow for control program development using formal methods

Formal methods provide significant advantages for control system design. They enable the early detection of design errors, guarantee correctness by construction, and clearly trace the link between the original specifications and the implemented control code. They are particularly valuable for safety-critical systems, such as robotic work cells and transport automation, where unexpected behaviors could lead to serious hazards or costly operational failures.

However, formal methods also have limitations. Building accurate formal models is time-consuming and requires specialized skills in system modeling and formal logic. As the complexity of a system grows, the number of possible states that need to be checked increases rapidly. This rapid increase, known as combinatorial explosion, can make the verification process slow or even infeasible. Due to these challenges, formal methods are most commonly applied in academic research or in smaller industrial systems where the modeling effort is manageable.

In previous research, our team has successfully applied formal methods in practical settings, specifically for discrete-event modeling and controller synthesis using model-checking tools like SUPREMICA and UPPAAL [17, 18].

Although formal methods continue to offer a reliable approach for ensuring correctness, their complexity and scalability issues have limited wider adoption in industry. Recent research therefore explores combining formal methods with artificial intelligence techniques. AI-based approaches can reduce manual modeling effort, improve scalability, and increase flexibility in the control design process. The next section examines these promising new directions, focusing on how AI can automate key stages of control program development.

The results presented in this section highlight the effectiveness of the proposed approach for extracting key components from natural language specifications in manufacturing systems. Using a dataset of over 2000 annotated descriptions written by control designers, we evaluate the ability of pretrained language models to identify entities such as actuators, pre-actuators, and sensors with high precision. Our analysis focuses on the structure of the dataset, the distribution of entity classes, the setup of the training process, and the comparative performance of BERT-Base and BERT-Large models. Through a series of figures and tables, we discuss the progression of training, the quality of predictions, and the trade-offs observed between model complexity and performance.

The dataset used in this study comprises 2135 natural language specifications written in English, each describing the intended behavior of components in automated manufacturing systems. To enable machine learning models to process this information, each specification was manually annotated using the BIO (Begin, Inside, Outside) tagging scheme. This format, consistent with the CoNLL-2003 standard [23], allows each token in the text to be tagged as either part of an entity (such as an actuator or sensor) or as general descriptive content. Three functional entity types were considered: actuators, pre-actuators, and sensors. All other tokens were labeled as "O", indicating that they do not represent a technical component. The final dataset contains over 76000 tokens distributed across training, validation, and test sets. The detailed breakdown is provided in Table 3.

Table 3. Annotated data distribution across training, validation, and test sets

Category	Train	Validation	Test	Total
Specifications	1708	213	214	2135
Sentences	3416	426	428	4270
Tokens	61065	7686	7669	76420
Actuators	1708	213	214	2135
Pre-Actuators	1708	213	214	2135
Sensors	3416	426	428	4270
Others	40385	5101	5073	50559

This distribution reveals that sensors are the most frequently occurring labeled entities, while actuators and pre-actuators appear in equal numbers. However, more than two-thirds of the tokens are labeled as "others", reflecting the descriptive nature of industrial specifications where control logic is embedded within broader contextual instructions.

To further illustrate the entity composition of the dataset, Figure 7 presents the distribution of labeled tokens across the four categories: actuators, pre-actuators, sensors, and others. As the figure shows, the "others" category dominates the dataset, accounting for over 66% of all tokens. This is expected, as requirement specifications in manufacturing often contain auxiliary information such as conditions, timings, and structural details that are not tied to specific components. Among the functional entities, sensors appear most frequently, followed by balanced counts of actuators and pre-actuators. This distribution poses a learning challenge, as models must accurately distinguish relatively sparse entities within a majority of general-purpose language.

image012.png

Figure 7. Distribution of labeled tokens by entity class

To ensure consistent evaluation and reliable generalization, the dataset was randomly divided into three subsets: 80% for training, 10% for validation, and 10% for testing. This split preserves the distribution of entity types across all partitions, which is essential to avoid bias during model assessment. The training set exposes the model to a diverse set of examples, while the validation and test sets allow for monitoring generalization and evaluating performance on unseen data. The proportions allocated to each subset are shown in Figure 8.

image012.png

Figure 8. Proportions of training, validation, and test sets in the dataset

Table 4. Token-level annotations with part-of-speech and named entity labels [19]

Token	POS	POS ID	NER Label	NER ID
This	DT	4	O	0
setup	NN	8	O	0
involves	VBZ	19	O	0
a	DT	4	O	0
double-acting	JJ	7	B-ACTUATOR	1
cylinder	NN	8	I-ACTUATOR	2
controlled	VBZ	18	O	0
by	IN	6	O	0
a	DT	4	O	0
5/2-way	JJ	7	B-PREACTUATOR	3
solenoid	NN	8	I-PREACTUATOR	4
valve	NN	8	I-PREACTUATOR	4
.	.	1	O	0
The	DT	4	O	0
cylinder	NN	8	O	0
moves	VBZ	19	O	0
forward	RB	13	O	0
to	TO	14	O	0
the	DT	4	O	0
FL	NNP	9	B-SENSOR	5
limit	NN	8	I-SENSOR	6
switch	NN	8	I-SENSOR	6
and	CC	2	O	0
then	RB	13	O	0
retracts	VBZ	19	O	0
to	TO	14	O	0
the	DT	4	O	0
BL	NNP	9	B-SENSOR	5
limit	NN	8	I-SENSOR	6
switch	NN	8	I-SENSOR	6
.	.	1	O	0

To illustrate how specifications were annotated, Table 4 presents a labeled example taken directly from the dataset [19]. Each token is associated with its corresponding part-of-speech (POS) tag and named entity label using the BIO scheme. This format enables the model to identify not only the type of component (e.g., actuator or sensor) but also its span within the sentence. While the structure is compatible with CoNLL-2003 conventions, the vocabulary and domain-specific terms reflect the language commonly used by control designers. This approach allows the model to learn technical patterns in realistic industrial contexts.

After building and annotating the dataset, the next step was to set up the training and evaluation process. This part of the study aimed to test whether the models could correctly identify the main components mentioned in the specifications. These components include actuators, pre-actuators, and sensors. To perform this task, two models were used: BERT-Base and BERT-Large. BERT was chosen because it is designed to understand the meaning of words in context, which is important when identifying technical terms in full sentences. It has also shown strong performance in tasks where each word in a sentence must be labeled, such as named entity recognition. Both versions of BERT were fine-tuned on the annotated dataset. Fine-tuning means taking a model that has already learned from general English texts and continuing its training on a specific dataset, so it can adapt to the language and structure of the domain.

To fine-tune the models on the annotated dataset, a systematic grid search was conducted to identify the optimal training configuration. We explored different combinations of learning rates and batch sizes for both BERT-Base and BERT-Large while keeping the number of training epochs fixed at three. This setup ensured a fair comparison of model capacity under consistent training conditions. The learning rates tested were 1e-5, 3e-5, and 5e-5, and batch sizes of 16 and 32 were evaluated. Each model was trained to minimize evaluation loss and maximize precision, recall, and F1 score.

Table 5 presents the full results of the grid search. BERT-Base achieved its best performance with a learning rate of 5e-5 and batch size of 16, reaching an F1 score of 0.9711, precision of 0.9778, and recall of 0.9688. BERT-Large also performed well, with its highest F1 score of 0.9667 under the same learning rate and batch size. These results confirm that both models can accurately detect components in manufacturing specifications, with BERT-Base showing slightly more stable performance across configurations.

During training, we monitored key performance metrics to evaluate how well the model was learning over time. These metrics included evaluation loss, precision, recall, and F1 score. Figure 9 shows how BERT-Base progressed across these indicators throughout 801 training steps. In the early stages, the model exhibited rapid improvements in both recall and precision, reflecting its ability to capture component patterns from the training data. Around step 200, performance stabilized, and the F1 score consistently remained above 0.96 in the later stages of training. The evaluation loss decreased steadily, indicating improved generalization. These results suggest that BERT-Base effectively adapted to the domain and was able to extract relevant entities from technical language with high accuracy.

image014.png

Figure 9. Performance metrics during training – BERT-base

To assess the influence of model capacity, we also tracked the performance of BERT-Large using the same training configuration. As shown in Figure 10, BERT-Large reached high scores early in training and exhibited stable improvements over time. While its F1 score surpassed 0.96 after approximately 200 steps, the overall curve showed more fluctuation compared to BERT-Base, particularly in the earlier and middle phases of training. Despite these variations, the model achieved competitive results, with its final F1 score nearing that of BERT-Base. The evaluation loss also followed a downward trend, confirming the model’s ability to generalize well. These results indicate that BERT-Large benefits from its greater capacity to model complex patterns, but this also comes with a slightly less stable training curve.

image015.png

Figure 10. Performance metrics during training – BERT-large

To provide a clear summary of performance, we compared the best evaluation metrics achieved by each model using a grouped bar chart. As shown in Figure 11, BERT-Base slightly outperformed BERT-Large across most metrics. It reached the highest F1 score of 0.9711, along with strong precision, recall, and a lower evaluation loss. While BERT-Large also delivered competitive results, its peak scores remained slightly lower under the same training conditions. This outcome suggests that BERT-Base offers a strong balance between performance and stability for the task. However, it is worth noting that BERT-Large has greater capacity and may yield better results if trained with a different learning rate, batch size, or number of epochs. Further hyperparameter tuning and model-specific adjustments could improve its performance in future work.

image016.png

Figure 11. Best evaluation metrics: BERT-base vs BERT-large

image017.png

Figure 12. Overlay comparison of BERT-base and BERT-large across four metrics

To better understand how the two models evolve over time, we plotted their training curves together for all key metrics: F1 score, precision, recall, and evaluation loss. Figure 12 provides this side-by-side visualization. The results show that both models followed similar learning patterns, with BERT-Base displaying slightly more stable trajectories across most metrics. BERT-Large showed stronger performance in some early stages but exhibited greater variability, especially in precision and recall. Despite these fluctuations, its scores converged closely with those of BERT-Base by the final training steps. This overlay comparison confirms that both models are capable of capturing the structure of technical language in manufacturing specifications, but BERT-Base maintained a more consistent learning behavior throughout the training process.

The results obtained from the component extraction step demonstrate that the BERT models are capable of accurately identifying actuators, pre-actuators, and sensors from structured technical descriptions. This confirms that the system can process manufacturing requirements written in natural language and extract the functional elements necessary for automation. The extraction process is now stable and precise, providing a reliable foundation for the next phase of our work.

image018.jpg

Figure 13. Pipeline showing component extraction and code generation from natural language specification

As shown in Figure 13, once the key components are identified by the model, the system can proceed to structure them into meaningful control logic. We are currently developing the module responsible for generating function definitions and control routines based on these extracted elements. This step aims to automatically produce Structured Text code that conforms to industrial standards. By extending the system in this direction, we move closer to fully automating the translation of requirement specifications into executable PLC programs scenarios.