Hvad er Time Sensitive Networking (TSN)?

What is Time Sensitive Networking (TSN)?

TSN is the latest extension of the Ethernet standard, but what does it consist of and how can it be used to synchronise devices on a network?

Introduction to TSN

Ethernet is a widely applied communication standard that makes up the backbone of the internet. It is standardised in IEEE 802.3 and is used for transmitting a plethora of data. It comes with the drawback that it is non-deterministic, i.e., there is no guaranteed reply time for requests over ethernet. For common internet traffic, determinism is not required, but for high-performance software and control processes, it is crucial that data arrives on time.

Several solutions have been made to introduce determinism in ethernet, for example EtherCAT which consists of a closed network with a fixed data frame that is transmitted at a high repetition rate. However, EtherCAT cannot be extended to an open network and does not allow other data than what has been predefined.

TSN is a general solution that allows deterministic communication on open ethernet networks. It requires TSN-enabled hardware but is backwards compatible so ordinary ethernet data can be transmitted on TSN networks.

Synchronisation

In order to deliver deterministic communication, a common concept of time is required, which is absent in ordinary ethernet. This involves the ability to synchronise different devices over TSN which is at the core of this post. Synchronisation is standardised in TSN under IEEE 802.1AS which is an extension of an earlier standard, IEEE 1588 also known as Precision Time Protocol (PTP). Therefore, TSN is compatible with PTP, but where PTP works on level 3 in the OSI model, TSN is a level 2 technology which makes it insensitive to network traffic.

Synchronisation in TSN is based on a master clock that all the other devices refer to. The master clock is automatically selected from the local network on the basis of what clocks are available and their specifications. If the master clock becomes unavailable, a new master is automatically selected to which the other devices will refer.

From the master clock, synchronization packets are sent to the other devices on the network. These packets measure the distance from the master to all slaves and this information is used to adjust the slave clocks when they synchronize with the master clock. In this way, TSN can take difference in cable length into account, as well as difference in response times and other imperfections in the network, in order to achieve a synchronous network.

Why TSN?

The quality of synchronisation in TSN is better than 1 µs by default, but it can often be improved, if the network is optimised. That means that TSN is an ideal technique for distributed data acquisition systems with high sampling rates, where large amounts of data is transmitted over the network. This makes TSN suited for, e.g., structural tests, where large units are measured with many strain gauges at sampling rates up to 100s of kHz.

Deterministic communication via TSN lends itself towards using Ethernet in systems controlled by real-time operating systems (RT-OS), such as machine control and hardware in the loop (HIL). Here, strict determinism is required, making ordinary Ethernet unsuited. For more information about this and TSN support in NI’s products, see here.

Hvad er hardware-abstraktion?

What Is Hardware Abstraction?

What is hardware abstraction, and what are the benefits when recording or generating signals for test equipment, data collection, or control systems among others?

Hardware Abstraction: Why and When?

When a computer program is to communicate with some hardware, a driver that provides the program with an interface to the hardware is needed. The driver is typically specific to a given piece of hardware, so when you use the driver in a program, you will, to a great extent, lock yourself to this instrument. Most often, you will not be able to replace the hardware without incorporating a new driver into the program, and you will therefore experience a very limited hardware flexibility.

The solution is to insert a hardware abstraction layer (HAL), so the program is separated from the driver. The program will only communicate with the hardware through the HAL, which means that the program does not need to know what specific hardware it is to work with. The program only knows about the hardware through an alias, which the HAL translates into the actual hardware. As all the specific details are hidden from the program, it is said that the hardware is abstracted.

A HAL makes it easy to replace one instrument with another, as you only need to let the program’s alias point to another instrument. Therefore, it does not require any changes in the software itself, but only in its configuration.

Read more about our knowledge of trade

Hardware Abstraction at GPower

Typically, hardware abstraction is implemented based on the type of instrument, so you can classify the instruments into groups. The challenge, however, is that a Type A instrument cannot be replaced by a Type B instrument, even though both instruments have the required functionality for a given measurement. As an example, both a multimeter and an oscilloscope can measure a DC voltage, despite they are widely different.

At GPower, we solve that challenge by basing our hardware abstraction on functionality rather than instrument type, which results in a greater flexibility in the use of hardware – and therefore also an easier data collection. All instruments that implement the same functionality can easily be replaced, and it only requires a change in the software configuration.

Hvilke hardware-platforme bruger vi, når vi bygger systemer?

What Kind of Hardware Platforms Do We Use When Building Systems?

With regard to our software platforms, we are building systems by using the programming language, LabVIEW, and the framework for test management, TestStand. But what about our hardware platforms?

Who Is Our Preferred Hardware Supplier?

In addition to our primary software tools from National Instruments (NI) consisting of LabVIEW and TestStand, our preferred hardware supplier is also NI, but why?

The reason for this is based on many years of experience showing that solutions, developed by using NI’s software and hardware, are high-quality solutions when it comes to developing specialized systems for test, measurement, and control projects.  

But what do we mean more specifically when saying high-quality solutions? In short, if you invest in a high-quality system, you will save time and money in the final analysis, as you for instance avoid having a system that fails, that is difficult to maintain, or that does not perform as intended.

Hardware Examples

Since most of our projects involve test, measurement, and control, it is primarily PXI, CompactRIO, CompactDAQ, and PC that we make use of. 

16 Xeon Kerner for Embedded Real Time [PXI Controllers]

16 Xeon Cores for Embedded Real Time [PXI Controllers]

Just another day at the GPower offices. A couple of National Instruments’ fastest PXI controllers have just arrived at our office this morning! NDAs prevents us from telling exactly what it is for unfortunately. That said, we can tell you that it is awesome as always working here at GPower!

A Couple of National Instruments’ Fastest PXI Controllers Have Just Arrived at Our Office This Morning!

Just another day at the GPower offices. LabVIEW Real Time running on Intel Xeon equipped PXI controllers: 16 Xeon cores / 32 threads. Add a couple of big Xilinx Kintex-7 FPGAs and some infrared 26 mega-pixel cameras. Hence, we have a potent system for one of our customer projects.

See an Extract of Hardware from National Instruments 

What Are We Using These PXI Controllers for?

Unfortunately, NDAs prevents us from telling exactly what the controllers are for. However, the project is about measurements regarding some of the biggest machines that we are capable of building today. A task that – once again – pushes our physicists and engineers into a situation where it is really fun to be! Care to join us?

Visit Our Career Site

Få kvalitets-controllere til helt andre priser end tidligere! [CompactRIO]

Get High-quality Controllers at Affordable Prices! [CompactRIO]

Previously, a high-quality controller has rapidly reached 30-40,000 Danish kroner. However, this tendency does not have to be the case anymore as National Instruments has released a new series of cRIO models at completely different prices than previously seen – prices that make it easier to start new projects and complete existing ones.

Get High-quality Controllers for Half Price!

Can your project be realized by means of one ethernet port instead of two and a more affordable FPGA? If you are interested in getting high-quality controllers for half price, which the new cRIO models enable, you are to ask yourself such questions!

GPower Is Provider of Hardware from National Instruments 

By using cRIO-9056 as an example: With the exception of the number of ethernet ports and another FPGA, the model has the exact same functionality as cRIO-9035. However, while the price of cRIO-9035 is 26,680 Danish kroner, the price of cRIO-9056 is only 14,010 Danish kroner.

In other words, with a few compromises you can get the exact same controller but about half the price. In addition, you will moreover get a controller that supports the use of NI-DAQmx directly from c modules without using FPGA which is not the case with regard to the more expensive model.

Get an overview of cRIO Controllers here

Start New Projects and Complete Existing Ones

Previously, many clients have avoided to start projects because even the hardware price has seemed infeasible and frightening. However, we believe that news like this can help to change this tendency. So, it will become easier and more manageable to start new projects as well as replace old hardware in existing systems in order to optimize and secure processes.

How Can We Assist You?

At GPower, we combine National Instruments’ hardware with our proprietary software when we are developing solutions for collecting measurements, generating signals, and saving data sets.

We do projects in various industries. Get an overview

Furthermore, we also assess what kind of solution that will be best for your project. And while we are on the subject of cRIO models, we often see that it can be enough having a controller to measure temperature and synchronize devices while the size of RAM and memory can have less importance. When it is important for you to do such assessments, it is due to the fact that it can have a great influence in relation to the hardware price. 

NIDays Steen Schmidt

CompactRIO – Adjusting Instruments

“Building High Precision Instruments with CompactRIO”. That was the headline for one of the presentations at NIDays, and it was given by our founder and CTO, Steen Secher Schmidt. In his presentation he shared with the audience his expertise in terms of what it means to build instruments using CompactRIO.

Brief Summary of the Presentation

Did you miss out on Steen’s presentation at NIDays in Copenhagen? Here we have some bullet-points from the presentation:

    • What makes an instrument user-defined?
    • How do we make sure that user-defined instruments can be maintained and developed futher with minimal risk and effort?
    • What are the most common mistakes in these types of projects, and how do we avoid them?
    • Do user-defined instruments always equal successful projects?
    • Why do we use GPower Actor Framework instead of NI Actor Framework?
    • How do we combine CompactRIO and LabVIEW?

Why CompactRIO?

When we use CompactRIO we do so with the aim to improve advanced control- and monitoring systems regarding everything from sensors and cameras to motors and actuators. Furthermore, we use CompactRIO to simplify complex applications when we assemble a number of sub-systems into one whole system where multiple different components is connected directly to the instrument.

GPower Is Provider of Hardware from National Instruments 

We are able to do so especially because we define the instrument’s software ourselves. Because of that, we can adjust the instruments as we see fit – even after implementation.