The Unity (UMAS) protocol (Part III)

This is the third part of a series of articles describing the Unity (UMAS) protocol used to configure Schneider Elctric industrial devices. It's a Schneider-Electric proprietary protocol used to configure Modicon PLCs and t's been obtained through a reverse-engineering process:

INDEX

Part I. Introduction, initialization phase, functions codes used in the initialization phase

Part II. Function codes used to read and write memory values from/to memory

Part III. Function codes used to deal with logic programs, and work with the PLC

Part IV. Other extra function codes

Part V. Modicon Premium PLCs specific function codes

---

In this part we'll talk about Unity requests regarding PLC logic(programs) upload and download process. In this entry I will talk about the logic or program running in a PLC as the

Initialize and finish a logic/program upload (“01 30” and “01 32”)

b>Important note:After upgrading to firmware version 2.7, the first byte (always was "01") varies. To know which is the value of this byte, please check request "01 04" on part I of this tutorial. In this tutorial I will keep writing this "01" byte in all examples, but that byte doesn't need to be there.

A program upload (computer --> PLC) process comprises three types of messages. The first message tells the PLC that an upload process is going to start. It's a single request (“01 30 00 01”) with no information in it:

It just informs the PLC that a program upload comes next. After this message is sent, Unity starts uploading “blocks” of data to the PLC. This is done with messages “01 31” that will be explained in next section. When last “block” is uploaded, a message “01 32” is sent to the PLC, notifying that the program upload (Computer --> PLC) process have ended in “N” data blocks.

Upload a binary block of the strategy (“01 31”)

The structure of an upload block message is the following:

Let's explain that:

• UMAS code (“01 31”).
• “00 01”. Always.
• 2 bytes with the block number that's going to be written in Little Endian mode, starting with “01 00”.
• 2 bytes with the block length. Little endian. In the following example this field has a “DA 00” value which means 218 bytes little endian. If we try to trick this and send more than 218 bytes (in this case), only the first 218 will be written in the PLC, if less bytes are sent an error message (“00 FD”) will be received.
• The 218 (or whatever) bytes. The maximum block size is negotiated previously in the “00 01” message (See part I of this tutorial).

When a program is downloaded or uploaded from/to a PLC, the data needs to have a specific structure. When from Unity Pro a program is saved to disk, it creates a zip-like file with a ".APX" file with exactly the same hexadecimal structure of the data sent to the PLC. That's why I call the structure of the data sent to the PLC as "APX file". This structure will be explained later in section VI of this tutorial.

For this reason, the data which is sent to the PLC can be read from a valid APX file. You can get one by downloading a strategy from the PLC or just unzipping a Unity STU project. The APX file has many integrity check all along the file. Therefore only a few bytes of the file can be modified.

The upload (computer to PLC) process is quite tricky. The first blocks sent to the PLC must have a specific length:

• Block 1 → 64 bytes (with the first 64 bytes of the APX file)
• Block 2 → 264 bytes (with bytes 65 to 328 of the APX file)
• Block 3 → 64 bytes (with bytes 329 to 373 of the APX file)
• Block 4 → 1014 bytes (if possible)
• Block 5 → 998 bytes (if possible)
• Block 6 → 1008 bytes (if possible)
• Block 7 → 1014 bytes (if possible)

After the 7th block, all blocks are 1022 bytes long (if possible, it depends on negotiation performed during connection. Have a look to sections I and VI for more information). In blocks 4 to 7, if the max packet size is lower than 998, they will be sent with the max packet size.

After many tests I realized that, the strategy upload process:

• need to be done with a minimum message rate
• need to be done in the appropiate order (starting with block 1, then block 2…)
• need to be preceded by the read of blocks 13h and 14h. This will be explained later on section VI
• if we add extra bytes at the end of the last block (until a max length of 1014 bytes), they will be stored in the PLC, however they will never be restored back when downloading, as during the download process is the PLC who decides the number of bytes to send.
• If the APX has suffered any modification, it will send back an error message.

Initialize and finish a strategy download (“01 33” and “01 35”)

The program-download (PLC to Computer) request is quite similar to the program-upload request ("01 30"). There are two messages that notify the start (“01 33”) and the end (“01 35”) of the download process.

Note that in this case (and the next one) the PLC was using a firmware version over (or equals to) 2.7 and the requests do NOT start with "01" but with a "random" number. This will be explained later.

The start-strategy-download message (“01 33”) will send the PLC the maximum packet size expected (In the following example "FD 03" in Little-Endian format, which means 1022 byts). The PLC's reply will be OK (“01 FE”) or Error (“01 FD ”).

The end-of-program-download message ("01 35") will check with the PLC the number of blocks received:

In this case informs that “55 00” - Little endian- blocks were sent, which mean 85 blocks. This is therefore the "01 35" request structure:

Download a binary block of the program(“01 34”)

After sending the start-of-program-download message (“01 33”), the strategy is requested block-by-block, starting with block 1, and ending when no data left is sent.

Let's see a real example. In the following example we are requesting block 07 (note the last two bytes of the request: “07 00”).

The response from the PLC is the block 7 of the program memory. In this case 1014 bytes long:

This process is repeated until no data is sent back. Note that the block 1 is always requested twice.

The data recovered (after the first 7 bytes) is appended to the APX file. When the process finishes this file stores the whole strategy, variables and other important information for Unity software.

Therefore the upload process (Computer to PLC) comprises the following requests:

1. 01 30
2. 01 31 + data
3. 01 31 + data
4. ...
5. 01 31 + data
6. 01 32

While the download process is done by sending the following requests and expecting the returned data:

1. 01 33
2. 01 34
3. data is returned
4. 01 34
5. data is returned
6. ...
7. 01 34
8. 01 35

Create, restore and remove a backup of the strategy in the Internal Memory card (“01 36”)

Although this requests is not part of the program upload or download proceses it's been added in this section because it's related with how the program is stored in the PLC.

The program is stored in the PLC memory, however it can also be stored, as a backup, in the external SD card included in the PLC. The process of storing, restoring and verifying the program storage can be performed with the "01 36" requests.

There are four "01 36" subrequests:

• Message “01 36 01 00 00” will make a copy of the running strategy into the internal SD card
• Message “01 36 02 00 00” will restore a previously stored backup from the SD card to the PLC program memory
• Message “01 36 03 00 00” will compare the backup stored in the SD with the startegy that's currently running in the PLC
• Message “01 36 04 00 00” will remove the backup currently stored in the SD card.

The messages are very simple (just the bytes shown en the previous four bullets). The response is either "01 FE" for OK or "01 FD" when an error occurs:

And this is all for today. In the following part we'll talk about function codes used to monitor System bits/words and variables, and about Diagnostic funcions.