Using Siemens Test Suite Advanced for Application Tests in TIA Portal

11 min video

Siemens Test Suite Application Tests allow you to test your code modules in TIA Portal quickly and efficiently by running automated test cases. In this video, we set up Test Suite and show you how to run tests on function blocks. We also demonstrate how to run tests on Safety function blocks.

Questions? Get in touch!

Learn more about Siemens Industrial Automation Products.

Intro

  • Hey everyone, thanks for joining! I’m Liz, co-founder of Outlier Automation, a Control Systems Integrator. Today, we’re going to dive into Siemens Test Suite in TIA Portal. I’ll start with what Unit Testing is and how that fits in with Siemens Test Suite. And then we’ll go through an example of how to use it. 

What is Unit Testing?

  • Unit testing is a software development method, which typically uses automated tests to check that modules of code logically perform as expected.  There are many testing frameworks that have been developed for modern programming languages and Siemens Test Suite is TIA Portal’s version of Unit Testing.  Test Suite Application Tests let us run test cases on interfaces of one or multiple function blocks and functions.

  • Let’s look at function block to see how we might apply an Application Test.   

  • I have a function block “fbIO_AnalogInput” called in OB1.  It has logic in it that evaluates the “rInValue” versus the “rInLowLow” and “rInHighHigh” values to see if the analog input value is below or above an alarm setpoint. We can use an Application Test to verify that the Set-Reset logic I have here actually functions as we expect, which is that once the “rInValue” crosses the “rInHighHigh” value for more than one second, it sets an alarm bit.

  • Unit Testing gives us some big advantages. It reduces startup time when we commission our code on a live system.  If we know before we download to a PLC that our alarms work, that’s a lot less testing time in a high pressure, expensive situation.  It also improves the quality of code because running automated tests allows us to test many more cases and combinations of logic faster than we could manually.  Both of these reasons allow us to build confidence that our overall solution will be robust and thoroughly thought through.

  • There are a few things to remember when developing unit tests.  It’s best to break down your code and tests into small test cases.  This allows you to build up pieces that you know work and to think of simpler tests that are useful.  Tests are not for simulating an entire machine or communication between external applications.  Think of a test instead as checking a black box where a function block is the box and the inputs and outputs are the interface parameters.  Check all your black boxes individually then the overall solution is the connection between those boxes. Finally, when you’re writing your code, think of what test cases you should check and ensure that your code will meet the desired outcome. 

  • Now that we have the basics, my coworker Nic is going to show you how to set up and use Test Suite. 

Environment Setup

  • Now let’s pull together everything we need to start building app tests in Test Suite. 

  • So it's important that we install PLC SIM advanced first so let's go ahead and download that. I’ll search Siemens PLC SIM advanced and version 4 is the latest version at the time of this video. Click in here. If I scroll down here's a link to the executable. 

  • I went ahead and finished that install offline so now let's grab Test Suite. I’ll search test suite advanced version 17 to match my portal version. click this link... and this should be the executable. As I mentioned earlier make sure you install PLC SIM advanced before installing Test Suite. The good news is we only need a license for Test Suite - not Test Suite and PLC SIM advanced as we'll see later Test Suite actually spins up a virtual instance of a PLC using PLC SIM advanced and it uses that to run the app tests, but it all happens in the background so, as long as we have the test suite license, we're good to go. 

AI Block Demo

  • Now let's get into the software with the demo. Alright, so we're back in the same project we had opened before. Let's scroll down, go to “Test Suite”, “Application Tests”. We’re going to add a new test case. Let's call it AI Test. The scope allows us to run tests on different PLC's, but we've only got one so I'll choose PLC one. 

  • Now we can set up our variable table, so here we're really just mapping tags, which are local to the test case, to the tags that we set up in our PLC project. So I only have two tags I want to do: input which I’ll tie to the wInValue of the block and then high high alarm which I’ll tie to the bOutHighHigh of the block. 

  • So now we can move on to writing our first Test case. the first thing I do is give it a descriptive name and in this step what I want to do is set the input high enough that it's over the rInHighHigh value, but I don't expect the alarm to come on because I'm only going to run it for one PLC scan and there should be a timer in that block which will debounce the signal so it'll only trigger the alarm if it's been high for five seconds. So the way I do that is first you can see we set the input to the value then we say run, for the number of cycles we want, and then we assert that the high high alarm should be false and every test case is going to follow that same format. So now that I'm setting up this next one, I want the error condition to be true after debouncing, right, so first thing I have to do is set my input. I’ll use the same value. Now this time when I run I'm going to use time instead of cycles and I'm gonna run it for 5 seconds. Once that's over we should assert that this time the high high alarm should be true. 

  • So let's try it out. Scope is OK and I'll hit run. OK, so it looks like both steps passed so that means that the assertion line in each step evaluated to true, but let's see what happens if I change the run time on my second step. So I believe it's meant to be a five second debounce so let's see what happens if I run it for only 500 milliseconds. Yeah perfect - so it looks like the second step failed. It expected true, but got false on that bOutHighHigh. And turns out it was a one second debounce. 

E-stop Test Demo

  • OK now let's go ahead with another example and this time we’ll actually do a test case on a safety block. So in our main safety routine we have this E-stop block right here - this guy will be perfect. So I'll go down to “Test Suite” and “add a new test case”. We’ll call this one “E-stop test”. I always like to split screen with my block for reference. Now the procedure’s pretty much exactly the same. 

  • We're going to start with setting up our variable table. So I'll set my local E-stop to be the input to the E-stop block. We'll have an acknowledge. And then we'll set this tag “Q” to the “Q” output of the block. Now, one interesting thing here is we can only read the instance memory of a safety block so to write to them we use the tags interfacing with that block. 

  • So in our first step, we'll start by setting the E-stop Ok. So to set that up, first thing I’ll do is set E-stop equals true, the “ACK” I’ll leave false because it will expect a rising edge. Then to run, let's do one second. And for our assertion, let's see, the “Q” should be false. Yeah. 

  • Ok, so for our second step we're going to acknowledge so E-stop we’ll leave true and then we'll set the acknowledge to be true as well. Run time one second and this time [for] the assertion - our “Q” should be true meaning that the block accepted the acknowledgement and passed the input signal true on the E-stop to the output “Q”. Let’s run. 

  • Ok, as expected, both steps passed so when the E-stop was Ok, but we hadn’t acknowledged, “Q” was false. After we set the acknowledge to true, “Q” went high.

E-stop Demo 2

  • So we’ll see that once we get rolling here, adding steps on is actually pretty easy. So let’s do another cycle of the E-stop. I’ll just copy these lines. Change this one to be not OK, so we’ll have the tester drop the E-stop and the assertion should be that “Q” is false. Then, I’ll need to restore it. So I’ll take this again. And let’s call that “E-stop Restored”. And then, finally, we’ll “ACK” one more time. 

  • We’ll run it. And all the tests passed. So we were able to verify the behavior of this drop if we drop the E-stop, acknowledge it, drop it again, acknowledge it again. And we could go on and on like that.

Outro

  • And that’s all for today! Thanks for watching! If you have any questions, send us a message at info@outlierautomation.com and check out the other resources on the blog on our website. Bye!

Outlier Automation