Whitepaper: Modularization from the User Perspective

Introduction

In CODESYS 3.5 SP17, we completed a major architectural restructuring. Previously, most of the programming system functionality was bundled into a single interconnected setup. Only CODESYS SoftMotion as well as the paid add-ons of the CODESYS Professional Developer Edition were separate. During the course of restructuring, we further extended this modularization deep into the core functionality. As a result, most of the programming language editors, fieldbus configurators, and code generators are now offloaded to their own add-ons. The same applies to large-scale features such as visualization or symbol configuration, to name two examples. In the core, important infrastructure features remain, such as the user interface framework (menu system, navigator, message view, etc.), the compiler front-end, and components for project handling and communication with controllers. It should be mentioned that in the future even more parts can be moved from the core to separate add-ons.

We will primarily use this modularization to separate the version cycles of the individual components. In the past, it was necessary to converge the entire CODESYS development regarding new features and improvements to a single date each year (namely the release date of a service pack). Features which were just barely still incomplete usually led to the service pack being postponed. Features which clearly did not fit into the schedule were postponed into the future by a full year. In our own interest as well as in the interest of all CODESYS users, we want to remove this interconnectedness so that in the future we can version and release each add-on independently.

For CODESYS users, there are a number of immediate and significant advantages.

Features are released promptly after completion and are available as soon as possible.
Beta versions of add-ons can be provided to interested users in order to have the possibility for punctual feedback. In doing so, a beta version of this kind can be run in an otherwise stable environment.
Unneeded add-ons can be removed, which is good for both storage space as well as overall performance.

Of course, this flexibility is offset by increased complexity. In this whitepaper, we want to describe the following:

Existing restrictions
Actions we have taken to make the complexity manageable
Recommended approach for typical use cases

The setup

The setup, which can still be downloaded from the CODESYS Store International, is complete. All components which were already part of CODESYS 3.5 SP16 and earlier are also included in the current setup. This means that users will have a familiar overall system after installation without any functional losses.

We believe that users should work out their individual combination of core system and add-on versions in their own time and not be forced to deal with it right from the start. We are also well aware that many users are not at all unhappy with the comprehensive package and maybe never want to make a custom combination. This is a perfectly legitimate approach which the tool is not intended to get in the way of.

The installer

The setup automatically installs a new global tool called CODESYS Installer. This can be used to manage all CODESYS installations as well as the add-ons associated with them. It is the pivotal element for users who want to actively benefit from the advantages of modularization.

The CODESYS Installer can be used to manage any number of independent installations. Within each individual installation, you can specify exactly which add-ons should be part of it. For clearer organization, each installation can be given a distinctive name. For each installation, you can set which updates should be announced. By default, this is set to "released versions only", but it can also be changed to prerelease versions or even turned off to lock the state of an installation.

For more notes about useful functions of the CODESYS Installer, see below in the recommendations.

Within CODESYS, we have linked the Notification Center to the CODESYS Installer. Notifications about suitable updates are shown here. Therefore, you do not have to keep running the CODESYS Installer to be notified about updates.

Compatibility

The keyword "compatibility" conceals the greatest increase in complexity which results from modularization. Whereas traditionally there was linear development and as a result the compatibility issue was simple ("the new CODESYS can read an old project"), in a high-modular environment the matter is incomparably more difficult.

The decisions which we have made and which are explained in more detail in the following sections have consciously been made not on the basis on what is technically feasible, but on what is reasonably manageable.

Project compatibility

The question here is to which extent an CODESYS installation can open a project or library which has been created with another CODESYS installation.

We have not changed this mechanism. The behavior is identical to the CODESYS versions before the modularization. If there is data in the project which cannot be read or interpreted with the current version because it was generated from a newer environment, then the respective objects are flagged with a red cross in the navigator, and identified with either [incomplete] (→ the editor can still be opened) or [unknown] (→ the editor can no longer be opened). In both cases, the project cannot be downloaded to the controller (because an undefined program behavior could result), and only Save as is available (in order to prevent accidental overwriting of the original project and therefore data loss).

This behavior has proven successful for years.

Code compatibility

The question here is whether or not in one CODESYS installation you can generate always binary-equivalent controller code for a project as with another CODESYS installation. In simple terms: Can you open any project with a CODESYS installation and log in to the controller without an online change or download?

For this purpose, there was the concept of the compiler version up through CODESYS 3.5 SP17. We will remove the compiler version as of CODESYS 3.5 SP18. If you need to be able to log in to a controller with a project without performing an online change or download, then you have to open the project with an CODESYS installation which is exactly suitable.

There are a number of powerful arguments for the decision to abandon the concept of the compiler version:

Not only the compiler is responsible for the generated code, but also the programming language editors and fieldbus configurators that are involved. As these have now been offloaded to independently versioned add-ons, there can in principle no longer be one unified, comprehensive compiler version. We believe that the attempt to bundle a variety of different add-on-specific compiler versions into a kind of compiler version profile is overly complex from the user perspective. For CODESYS UML (part of the CODESYS Professional Developer Edition), there has been a separate language model generation version for years, but even with this one add-on, this concept has not proven itself in practice, let alone with the current multitude of add-ons.
In its simple form, the compiler version has already required detailed user knowledge. At the very latest, correcting an accidentally incorrectly set version was often problematic. Users who had bad experiences with this, or who were generally not convinced by this concept, had already performed multiple maintenance installations in the past in order to be able to log in safely to running controllers in the event of maintenance. As we will see below, we now provide robust interactive support for this case.
Every new compiler version inflates our internal code base. On the one hand, this has a negative impact on performance and on the installation size. On the other hand, we can by no means test all combinations in this code base. Furthermore, as compiler version maintenance is also error-prone to a certain extent, this is in direct contradiction to our continually increasing demand for quality. In other words, we cannot guarantee that the previous compiler version concept will work reliably in all cases, and we would be even less able to do so if we had to make this concept even more complex due to modularization.
The two previous arguments can be summarized as follows: It is attractive from the user perspective to be able to produce a reliably suitable version for the case of maintenance by means of our tool support without having to deal with a compiler version at all.

Runtime system compatibility

The question here is to what extent a CODESYS installation is compatible with a runtime system version. In other words, can you log in to an old controller with a new CODESYS installation and use the available online functions?

We have not changed the associated mechanisms. Basically, programming system versions and runtime system versions can be combined in any way, with the following limitations:

A new programming system version may provide functions which an older runtime system version does not yet support. In this case, the function is not available.
An older programming system version may not work with a newer runtime system version if security enhancements prohibit it (for example, enforced user management or a new type of encryption algorithm).

Recommendations for users

The scenarios described in this section can of course also be used in combination. We believe that this covers the overwhelming majority of practice-relevant cases and would like to support them as best as possible with our tools. In the future, we also want to further optimize our software according to these use cases.

Scenario	Recommendation	Tool Support
Everyday development on a running project	The CODESYS version as well as the accompanying add-ons should always be kept up-to-date. We are constantly working on big and small improvements, bug fixes, and security updates so that the newest version is always the best version ever. There is little reason to hold on to old versions.	The CODESYS Installer shows all updates which are available for an installation. These updates can be downloaded and installed with just a few mouse clicks. Furthermore, the Notification Center, which is integrated in CODESYS as a dockable window, also lists available updates (exactly suitable to the currently executed installation). From here it is possible to jump directly to the CODESYS Installer so that it does not have to be continuously active. All setups and add-ons provided by us are signed. Therefore, downloading them over the Internet is safe. We have extended the Package Manager with corresponding (partly interactive) test methods.
Everyday development on an running project under the constraint that several people in a team have to use a uniform installation	As above. One person in the team installs available updates on their own and tests them. Upon successful clearance, the new reference installation is distributed within the team.	In the CODESYS Installer, existing installations can be exported as a description file. This file can be used to create an identical installation on another machine. This mechanism is also available from the command line, so it is particularly suitable for automated environments.
Trying out the newest add-on features in a safe environment	An existing productive CODESYS installation is duplicated. In this installation, any beta versions of add-ons are installed and updated as needed. The CODESYS installations which are used productively remain completely untouched by this. Normal work on projects is not affected.	The CODESYS Installer allows you to easily create a copy of an existing installation. For each installation, you can choose whether only released updates or also experimental beta updates should be provided and installed. Previously, a particular service pack or patch could only ever be installed one time on each machine. Since the introduction of the installer, this restriction has been lifted.
Maintenance on an existing controller without changing the associated existing project. There must be a guarantee that it is possible to log in to the controller without performing an online change or a download.	A CODESYS installation is created which is exactly suitable to the project. Without having to deal with compiler versions, the generation of binary-equivalent controller code is guaranteed.	If differences between the current CODESYS installation and the created version are detected when loading a project, then you are given the option to download and install an installation which is exactly suitable to the project. The project will then be opened automatically in this new created version. Furthermore, when loading it is of course possible to select suitable installations which already exist on the machine. In CODESYS Installer, installations get a user-defined name. In this way, you will not get confused if you have to manage a large number of installations. In order not to continuously receive update suggestions for such a special compatibility installation, these are separated from the update channel by default.
Further development on an older existing project	The project is further developed in a current CODESYS installation. Because changes are made to the code anyway, the pending online change or download is irrelevant.	As before, CODESYS can load older projects without any losses. If a required add-on is missing, then it is possible to download and install it directly from the project load operation. Otherwise, write and download protection protects both the project itself and the controller.