Testing critical infrastructure over 450-MHz networks

What and how to test with the software intaQt

Hello! My name is Can Davutoglu. I am the chief marketing officer of QiTASC. Today, I would like to present how we test critical infrastructure.

We have a 450-MHz network, this is how our critical infrastructure is designed, and we have the main three use cases. One use case is the communication between 450-MHz devices. The second use case is that we have some smart meter and that we have some sensors or equipment which also uses the 450-MHz network. For instance, there are sensors at, let´s say, a chemical plant and sensors measure the air quality, or something like that, and we need the data communication.

The network is provided. We have different kinds of devices and equipment, and we have developed intaQt. intaQt is our test automation infrastructure. It is software-based, and we control the devices.

We integrate ourselves to the mobile devices, for instance. We connect ourselves via USB. We can do everything that a user, a human being, can do with these devices. We can make phone calls, we can make data sessions, and so on. Fully automatically and even with kind of a remote control, so that a tester that sits somewhere in the world can remotely access these devices, see what happens on the device, and interact with his mouse.

We also integrate ourselves in an environment where a smart meter is available. We have some electronic components, with which we can also control power. For instance, we can activate the TV. The power consumption of the TV starts and what you consume you will see here in the smart meter. This information will go to a backbone. We have backbones for certain applications. This is a 450-MHz data communication, and here in the backbone there will be a database where the power consumption of this smart meter is entered. We can also integrate ourselves in this backbone: On the one side we control the TV, which generates power, the measurement is done, it is transmitted via the 450 MHz, and we check in the backbone that everything went fine.

You also have some other test use cases. For instance, you want to change the tariff at the smart meter. We also control the OTA, we apply the tariff and again run our power consumption, measure the data, and in the backbone we also collect the charging information and verify that everything went fine.

In a similar way we act with other sensors. We have electronic components which we connect to this, or this is a LAN router running some applications. One of the applications can be some measurement. We also control these measurements and trigger them. Then again, the measurement somehow goes to the backbone and triggers some interaction with the backbone. On that side, we check if the data transfer has been established and everything was fine. We do more measurements and process them. In the same way we do it with some other sensors.

What we do is: We try to collect all the end points. These end points are triggered by us, or we trigger something which is close to these end points. We take the measurements, we check the charging, we can collect the traces in the network and verify the signalling. We do everything end to end.

This is the most important thing: That such a critical infrastructure really works end to end, within the network and together with the application which makes use of the existing 450-MHz network.

A theoretical example of intaQt in an IoT infrastructure

Hello, I am the CEO of QiTASC and I will try to explain to you how we deal with IoT environments in order to test them. For this purpose we have selected a smart meter use case.

As you know, a smart meter is a very important device, especially in these times of energy crises. A smart meter gives a lot of valuable information to people in their homes, and to the power companies.

Let´s say we have a smart meter. This smart meter provides in the whole city. And we have a backend infrastructure with some IT systems that interact with this smart meter. This is the main thing happening and of course we have our house with different devices inside. We have a washing machine which is switched on and other devices like a TV and so on.

These are of course all connected to electricity supply. In the smart meter, this generates some information.

Now we want to test all this infrastructure. What do we do?

We set up an intaQt which is our test automation infrastructure. We have the intaQt server. We connect the intaQt server to one of these devices which we can control. Later, we will generate some activity here with power consumption.

On the other hand we have some devices which can read the smart meter. And we connect intaQt to these devices as well. This already lets us get the information between the smart meter and what is generated.

Then we are also connected to the IT system which is communicating with the smart meter.

On intaQt studio we write a script. First we trigger an activity, we start the washing machine. We know exactly how much power it will consume, so we can say that after one hour we have power consumption of x kW. This is recorded by the smart meter.

Then, as a second step, we read this power consumption information and while we are doing this there is an interaction between the smart meter and the IT system.

In the third stage, we will go into this IT system and read the data which has been generated in the IT system. Then we will correlate all this information and will know when the appliance was used, how much power was consumed and finally which data has been generated in the IT system.

Fourthly, we will correlate all data. And this will be done automatically.

As you may imagine, there are hundreds of thousands of variations. You can change the software on the smart meter which could be an additional activity and then run the requestion test cases.

The smart meter also generates some other power-related functions. You can read them, correlate them, check in the IT system, do some provisioning tasks in the IT system. So all this can be done automatically.

Let´s say 1A and 1B because provisioning is done first and correlate everything with each other.

So this is the setup we have in the IoT infrastructure. We set up the infrastructure as close as possible to the real world. We use real devices which are also used by the technicians at the power plants and power companies, we connect to them, we access their databases and correlate all the data automatically.

This is mainly what we are doing in IoT.

Interested in more? Visit us online! www.qitasc.com

Hello, my name is Bernhard from the electronics department of Qitasc. Today I would like to present an IoT project with an IoT test case.

The system we are testing consists of a system that is installed at home, a smart hub from the company Samsung in this case, and a door-window-contact as example. We can also use other devices, but in this case I would like to demonstrate a test case with a door-window contact. And a mobile phone.

We want to test the behaviour that you have at home. You have attached the door-window-contact to a window and want to receive a notification on your mobile phone as soon as someone opens the window.

Now we want to test both ends automatically. We do this by not mounting the door-window-contact on a window, because how do you open a window automatically?

We have mounted the door-window contact on a device that has a servo motor attached to it and this servo motor can open the window, so to speak. It folds the door-window-contact away from the magnet. Here is the magnet, here is the door-window contact. This part can be folded away and closed again.

The door-window-contact is connected to the Samsung smart hub via the Zigbee radio protocol and the Samsung smart hub is connected to a backend server at Samsung via the internet.

The phone, on which an app is installed, is also connected to the backend server at Samsung and via this connection, the connection to home is established. When the sensor detects that the window is opened, the information is transmitted to the backend server at Samsung. The phone is then notified that the window has been opened and is supposed to display this on the app.

That’s what we want to test. In order to do this, we have this servo motor. This servo motor is controlled by our electronics.

This is the board with the electronics. Of course, it can do much more than just control the servo motor; all the functions are also integrated. It is important to know that there is a Raspberry Pi in the background. This Raspberry Pi is also connected to the network and can be controlled by us. It then controls the functions on this board. I can connect four devices to this board.

In this case, only the first device is connected, here this door-window-contact. Via this platform that I have here, I can not only control a servo motor, I can also control many other functions.

For example, I can also simulate the battery here. So, there is no battery inserted in this sensor, but a battery dummy is inserted. This battery dummy is supplied by this circuit board.

With it I can also test, for example, the case when the battery becomes empty, that the device tells me that I have to replace the battery. I can also use it to switch relays and perform many other functions, adapted to the application, which is needed for the automation of a smart home.

The test case is processed via the intaQt studio as usual, which is our platform. Various steps are carried out in this test case, which are formulated almost naturally in terms of language.

We start by wanting to get the phone: Give my phone as A. Here even the serial number is given. That means I get a phone that has to be connected to my machine with this serial number.

And insert a full battery into the device multipurpose sensor demo. The device here, this door-window-contact is a multipurpose sensor. It can do more than just door-window-contact, that’s why it’s called a multipurpose sensor. And I put a full battery into that.

Then I open the app on the phone. And close the window monitored by the sensor MultiPurposeSensor_Demo. I make sure that the servo motor brings the door-window-contact into the initial position “closed window”.

Then on A – That’s the phone, we got it and called it A. Then on A, select the device MultiPurposeSensor_Demo from the devices menue. So on the phone the app is opened and in the menu of this app we go to the sensor we want to look at.

And on A, assert that the contact sensor of the MultiPurposeSensor_Demo says “Closed”.

We have previously set the sensor to the initial position “closed window” and now also want the app to indicate that the window is closed as an initial condition. And then the actual test begins.

Then open the window monitored by the sensor MultiPurposeSensor_Demo. This means that with this command, the servo will swing the sensor away from the magnet. This will look to the system as if the window is open.

Then we give the system three seconds to wait. And wait for 3 second, so that there is really enough time for the sensor to notice this and for it to be transmitted. That’s often a problem with automated test cases, that you don’t expect the machine to be that fast. Much faster than you would be as a human being.

So the automat can do that almost simultaneously, but that would go wrong. So you have to give the sensor the opportunity to react, to transmit it all, to play through to the backend server at Samsung and then down to the phone. And that’s why there’s a three-second pause It’s also easier for us to observe what’s happening that way, because it’s slower.

And on A, assert that the contact sensor on the MultiPurposeSensor_Demo says “Open”. That means we want to see after three seconds that the app shows that it is open.

And again we wait for three seconds: And wait for 3 seconds. Then close the window monitored. That means we shut down the sensor again. This time we even wait for six seconds and then we see that the app again shows that the sensor reports closed.

I will now start the test case:

The phone is now received from our test machine. The test case name is already displayed. Then the app is started. The sensor is navigated to in the app. And then it is verified whether the initial condition is correct. It said “Closed”. It opened, now it says “Open”. After a waiting period, it then moves back to “Closed” and we also want to see that it says “Closed” again.

This is the case. Test case is green and has the state “Passed”. So it worked.

We want to look at what would happen if the test case went wrong. Would we notice that?

I will start the test case again and then I will intervene so that the window cannot be closed. The sensor will continue to report “Open” even though the window is supposed to close.

Now it has moved to the initial position “Closed”. It is navigated to the sensor. The sensor must show “Closed” as initial condition. That is the case, it is “Closed”. Now it is opened.

Now I hold my finger inbetween and make sure that the servo motor can no longer move the sensor back to the “Closed” position. This means that it continues to display “Open” even though it has actually closed the window, and that is an error.

And this error has also occurred here and has been detected, in this case: on A, assert that the contact sensor of the MultiPurposeSensor_Demo says “Closed”. But it still showed open. It is an error. It has been detected by our machine and displayed accordingly.

Interested in more? Visit us online! www.qitasc.com