3

I have to create a overview documentation for a simple PLC (programmable logic controller aka industrial automation controller) program (happens to be written in Step 7 but not really important).

The structure of the program is simple. The functions i.e. "activities" are run one after another. Each activity reads a specific portion of the local memory. I want to represent those memory-portions as "input" signals because other Functions may/will write to the memory and it is not "just" memory but some sort of data transfer. The result is then again written into the memory for following functions. It is basically the Output signal of the function.

I tried to create a simple UML activity diagram. To represent this in the program i used the "Accept Event Action" and "Send Signal Action". Figure is shown below. I wanted to use the activity diagram because i then could also model the inner functions with the same type of diagram.

But it seems a bit confusing with the arrows downwards (from activity to activity) and left to right (data process output) And how should multiple readings be handled ? ( e.g. Function 1 and 2 read from the same source)

Do you have a recommended scheme for modeling this behaviour or ideas to "clean" the diagram?

Greetings Ari

current scheme i tried

2
  • What is PLC? Please expand that acronym! Dec 27, 2021 at 10:44
  • Done. PLC = programmable logic controller aka industrial automation controller.
    – Ari
    Dec 27, 2021 at 10:57

1 Answer 1

2

Your diagram has some hidden concurrency issues whenever you have multiple incoming or outgoing flows. Function 1 will for example simultaneously send the signal and pass over to function 2. But function 2 has 2 incoming flows and can start only when both present a token: the signal is received AND at the control is passed. This means that if function 1 wiuld have nothing to send. your activity would be stuck awaiting for function 2 to start.

This does not fully correspond to your rather input/output oriented sequential narrative. If function 1 provides data to function 2, it doesn’t really matter in the AD how it is implemented, but the semantic matters. You may therefore consider:

  • using an object flow between function to function. Buffering of objects is fully supported.
  • using a central buffer allows to highlight the fact that there is an in memory store as described in your natrative. You could then show an optional incoming signal, also feeding the central store, but from external processes/programs/activities outside the scope of your AD.
1
  • 1
    Thank you verry much. I will try the "Data store". Since there are multiple functions i think a somewhat complete "object flow" is to meshed. The main problem I have that I want to separate three Signal types: input , output and local data between the Functions (can be shared to multible different functions at the same time ) but its essentially the same memory. For the data/memory sharing I will try the "Data Store" next.
    – Ari
    Dec 27, 2021 at 10:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.