Eclipse 4diacWiki/Development/Modeling Implicit Assumptions

Overview page of GSoC 2023 Project

The aim of this project is to provide better infrastructure for observation and early error detection of modern automation systems, with inspiration from contract-based design (CBD).

Topic

Eclipse 4diac: Modeling Implicit Assumptions within IEC 61499 Software

Project Goals

Automated software engineering helps developers of control software to manage complex industrial applications. Eclipse 4diac has, in recent years, advanced in terms of providing tool support for domain experts. The control software is typically executed in real-time and distributed across devices. To detect faults early, modeling implicit assumptions within IEC 61499 software can provide the basis for automated checks. A key goal of the project is to deliver tools for creation and evaluation of such assumptions described in constraint language. Where user interactions are required, graphical visualizations are provided.

Milestones

Implementation Plan and CBD in 4diac IDE

CBD already has a lot of literature but no implementation in 4diac IDE, so the following implementation was chosen. A contract consists of Contract Elements that follow a CBD language. All implementations were created in a dedicated plug-in in 4diac IDE.

Decided on the following syntax for Contract Elements:

• ASSUMPTION EVENT occurs every TIMEms
• ASSUMPTION EVENT occurs every TIMEms with TIMEms offset
• GUARANTEE Whenever EVENT occurs, then event EVENT occurs within TIMEms
• GUARANTEE Reaction (EVENT,EVENT) within TIMEms
• GUARANTEE Whenever event EVENT occurs, then events (EVENT,EVENT) occur within TIMEms

EVENT is replaced by a user selected event pin. TIME is replaced by a user input, e.g. an instant (7) or an interval ([7,9])

A menu entry and dialogues for user interaction to create a contract are needed. The contract data needs to be stored so that no major rewrite of existing models is needed. The user only sees the Contract. All the evaluation and simplification is done in an IEC 61499 model in the backend of 4diac IDE without additional inputs except for the contract that was specified by the user.

Implementation Steps

Input Dialog

Manually recording the contract in a constraint language needs an understanding of the constraint language and an exact sequence of characters because a wrong space leads to a invalid contract. Dialogue windows were integrated into 4diac IDE to help the user generate correct contracts. For every Contract Element a dialog was implemented. The following screenshot shows the Dialog window for creating an Assumption. Similar dialogs were created for guarantees (depending on the selection, the version for 1 or 2 output pins is shown) and reactions. Guarantees can have an optional offset that can be selected by the user.

(Commits 204206, 203447 , 203488, 203587, 203653, 203718, 204012, 203659, 204014, 204160, 204161, 204167, 204546 )

Contract Model

The Contract is visualized as the comment of a SubApp with a name starting with _Contract. This implementation was used because the contract should be visible by the user and stored in a standard-compliant format. The implementation also uses already existing models(e.g. SubApps) and does not interfere with any already existing systems. The contract model builds a core of classes that describe the elements of a contract. Instances of these classes can form a representation of a The essential parts of the contract are extracted by helper classes from the String that is provided by the user. The contract model uses its own time classes to represent an Instant or an Interval. The representation allows to provide helper methods for (Commits 204154, 204249 , 204313, 204450)

The next figure shows an example for a contract defined over an FB:

Contract Elements

a) Assumptions

b) Guarantees

Contract

Contract Exceptions

The Contract Model has its own Exceptions with a field to store the contract or the contract element where the exception occurred. Commits 204112, 204349

Model Tests

Tests for the Contracts Model are implemented to validate their correctness. The are realized as Junit tests and included in the tests of the model plugin. They test, among other things, the following aspects:

• whether the Strings representing the Contract Elements are correctly imported and the model is created correctly. Based on this model, it is validated whether the information is correctly transcribed into a String again.

(Commits 204355, 204390, 204393, 204364)

• whether two Contract Elements that work on the same Events are simplified correctly

(Commits 204401, 204394)

• whether the validation of the contract is correct regarding its consistency

(Commits 204390, 204408)

Not merged

Not all improvement proposals were merged. As the contract is stored as a comment, it can be currently edited by hand. Removing the possibility of editing contracts by hand fixes this. However, the stakeholders were uncertain whether a manual editing is required. The commit can be merged at any time if needed. Commit 203558

Final Report (Summary)

In this Google Summer of Code-project, the infrastructure for CBD was added directly in the IDE. 4diac IDE now supports a constrained language for the creation of contracts. This includes an internal model to handle the contact and its elements. As is common for projects that need to work well with an already existing code base, extra care was given to integrate the basic function of CBD without limiting its expansion or classing with other functions of 4diac.CBD is a powerful new infrastructure for 4diac that has much room to expand the capabilities of 4diac. As a result, some of the topics (e.g. the interaction of different contracts) could not be researched in-depth, yet a working testcase is available as part of Eclipse 4diac. All the deliverables described in the project proposal were merged into the 4diac IDE repository.

A list of all my commits is available under the following link: Gerrit