Update B&R score, add Yes to Open Docs for Beckhoff

[shanereetz]

B&R Automation Studio checks a few more boxes than are currently marked. Beckhoff has open docs, so that has been updated as well.

Here are some sources:

Plaintext

I'm not sure where the docs explicitly say this, but I can share from experience that C and ST files are all stored as pure plaintext. VAR and TYP files are also plaintext and easy to edit outside of Automation Studio.

For reference, here is a Loupe open-source library for AS with plaintext code: https://github.com/loupeteam/Piper/blob/main/src/Ar/Piper/Piper_PackML.c

Testing framework

While I haven't used this framework much, it does exist. https://help.br-automation.com/#/en/4/technologysolutions%2Fts_unittest%2Fgeneral%2Fts_unittest.html

Open Download

Downloading and using AS simply requires an account. https://www.br-automation.com/en-us/downloads/software/automation-studio/automation-studio-412/automation-studio-v412/

Open docs

Until recently, the docs had to be downloaded. They are now available online like InfoSys. https://help.br-automation.com/

Note: I also added a yes for Beckhoff in this category as InfoSys is freely available online https://infosys.beckhoff.com/index_en.htm

[zantiu]

For the testing framework: it looks it only tests the C/C++ code? Not IEC 61131-3? https://help.br-automation.com/#/en/4/technologysolutions%2Fts_unittest%2Fgeneral%2Fcomponentsofatestprogram.html

The main expectation is that the IEC 61131-3 (or iec 61499) programs can be tested.

[zantiu]

All your proposals already added in https://github.com/SASE-Space/ot-openness-comparison/pull/8 , except for the testing framework where we should clarify if the IEC 61131-3 can be tested

[shanereetz]

I should have provided more clear documentation in my original post. While the tests themselves are written in C/C++, the documentation says IEC code can be tested using that API.

According to this page:

The unit tests are written in C / C++.
Code tested in this way can be written in IEC, C or C++, however, because the API is used for testing. The API for a dynamic library is defined using *.VAR, *.FUN and *.TYP files.

As a light demonstration, here are screenshots from one of the sample projects provided by B&R. On the left is an empty ST FB ready for TDD. On the right is C code defining the tests for the ST code.

And here is the FUN file

Does this match our criteria more appropriately?

[zantiu]

Ok updated with a direct commit since we switched to emojis. I think everything in your PR should be covered.