dataesr/scientific-paragraphs-categorization huggingface dataset:
This may be a problem when the platform is operated by an M2M service provider which is not involved in dealing with the semantics of the data transmitted. For example, an M2M service provider may carry data originating from health body sensors and simply route this data to the processing center for interpretation. Trust may then be the issue for this type of confidential data. If the platform is privately operated, then having the data available in clear at the level of the platform may require putting in place security measures to minimize the risk of data compromising, thus increasing the operating cost. In both cases, an end-to-end data protection scheme would constitute a better solution. Our security contribution is related to the definition of security architecture suitable to achieve end to end data protection and compatible with the ETSI M2M platform architecture.
Read/write access to this container will also be managed by the platform based upon authorization decisions made by the authorization server. The M2M service platform will enforce policy decisions made by the authorization server acting therefore as a Policy Enforcement point. In a first step and ahead of any data exchange, an initial enrolment procedure takes place. The owner of the device registers the device with the service platform and with the authorization server and also defines read/write access rights policies to this device. In this phase the owner of the device typically grants read access to the device to the M2M application. This enrolment phase results in the distribution of long term credentials (typical expressed in months or years) for the device and the M2M application making possible for them to authenticate with the authorization server.
When opening a data session the long term credentials are used both by the device and the M2M application to create shorter lifetime credentials used to actually protect data communications during the session time which can typically extend from a few hours to a few weeks. The device, after authenticating with the Authorization server will obtain a digital access token bundling together two distinct credentials:  Session encryption keys for private consumption used to cipher/decipher sent/received data( in our scenario, the data sent);  Signed authorization token for public usage to be presented to the M2M service platform along with a data write request. The M2M application, after authenticating with the Authorization server will obtain a similar access token; It will use the Session encryption keys used to cipher/decipher the data sent/received from the device (in our scenario the data received), and will present the authorization token to the M2M service platform in order to gain read access to the container holding the data sent from the device.
The flow of operations involved in a typical write/read operation is shown in Figure  17. The M2M Application first issues an initial unsuccessful read request to the M2M service platform and is subsequently redirected towards the authorization server to authenticate and obtain an access token. This token will contain the same data ciphering keys as the one delivered to the device. It will also contain an authorization token to present to the M2M service platform in order to gain read access to the device data. It should be noted that the ciphering keys are kept private both by the device and the M2M application. This opens the possibility to achieve end to end data protection between the device and the M2M service platform and to benefit from the data distribution services of the M2M service platform without having the data available in clear at the level of the platform.
It may happen however that some of the services offered by the M2M service platform require access to the data in clear. Semantic analysis or context awareness is example of such services. In this case, the platform acting as an M2M application, will be registered as a valid data recipient by the device owner, and will obtain the session keys needed to cipher/decipher the device data. Now, M2M applications often involve the need for one to many communication schemes. For example, the data originating from one device may need to be transmitted to several receiving applications, possibly using a publish/subscribe mechanism. The security architecture described here is perfectly suited to support this type of communication. The ciphering/deciphering keys distributed by the Authorization server are in fact group keys to be distributed to all parties involved in the communication scheme.
Therefore, it is better to apply application domain specific models for the semantics of M2M application data and not to include it into the horizontal service capability layer specifications;  Another challenge regarding the place of semantic reasoning services in the Service Capability Layer. The Service Capability Layers were designed in a way so that they only act as serving hatch for information. Certain data may be sensitive and confidential, so they are often encrypted; only emitters and final receivers of this information have the necessary credentials to decrypt it. In this case, the semantic reasoner shall be placed somewhere in the data receiver application otherwise no reasoning can be done. From the implementation point of view, ETSI M2M SCL assumes that M2M applications know all the details of the device installation and data interpretation.
The graph-based characterization allows the definition of consistency preserving reconfiguration mechanisms. On the other hand, it still possesses the functionalities granted by the standard, such as discovery protocols and machine interoperability;  The end-to-end security architecture model has been implemented in a prototype demonstrator using Arduino devices. The initial enrolment of the devices resulting in the definition of the long term credentials was performed using an out of band channel. The HTTP transport protocol was used both for communication with the authorization server and the M2M service platform. The evaluations show the provided architecture enable end to end data protection between devices and M2M/IoT applications and compatible with emerging interoperable M2M service platforms.
Such architecture revolves around the use of an Oauth authorization server issuing digital access tokens serving both the purpose of protecting the data from one communication end to the other, and gaining access to the data distribution services offered by the M2M service platform. Apart from offering end to end data protection, this architecture makes possible to avoid data being available in clear at the level of the service platform therefore eliminating the possibility of data compromising at the platform level. In the next step, the prototype will be extended to include smaller devices too constrained to support http protocols. In this case, the CoAP will be used for communication between the device and the M2M service platform. The dialogue between the device and the authorization server take place via an intermediate CoAP/http proxy.
Car Sharing Case Description The car sharing case has been visualized in Figure  20. The system has been built to provide real-time car sharing services such as e. g. , monitoring the status and location of the cars etc. In the experimental system, a car is connected via 3G/GPRS to a Car-sharing web application that shows real time the relevant data that comes from the car. The data is collected by some sensors that can be placed in the car, in the parking spot, or in any other provider of the car sharing scenario. Also the data that manages the application can come from any other external provider of the car sharing business as the car maintenance provider, cleaning company etc. For example, if the car sharing company wants to know the state of the doors, while the customer is using the car, we click on the button doors in the web application, this application sends (in a standard format) to the car the request of the state of the doors via the M2M gateway, and the car returns the data via standard XML-format.
Or a Car-sharing customer wants to make a reservation, a code is sent to the customer for reserving a determinate car, after this the customer will be able to open the car with his mobile phone (NFC system). The idea is that the car is managed and monitored by the car sharing company, providing many services to the customer in order to rent the car whenever is necessary with the maximum flexibility. A key novel component of the system is the A2Nets Gateway functions executed within the on-board computer of the car. The gateway has three different connections to devices: CANBUS gets car values such as speed, fuel status, status of doors and windows, etc. ; The GPS sensor provides the car localization; The NFC Sensor authenticates the user's from NFC tag or mobile device to allow open or close the door.
In the car also there are wireless devices (IR and RADIO) that communicate with wireless sensors of the parking, so that they know the location of the vehicle inside the parking house. The A2Nets gateway connects the sensors into the back-office server. The Server contains the general database system and a range of services to interact with other actors. From the car collects data in real time and historical of localization, speed, fuel, etc. From Parking gets the position of the place where is the vehicle to offer the customer who wants to rent it. Sends a customer keys to the car in order to client can open the door by NFC authentication. Also, allows client to make the reservation of a vehicle and know the basic statistics of client trip. When parking a wireless sensor detects the vehicle that is parked in a particular position.
The Computer Parking automatically sends the data to the Car-Sharing company. Similarly, when the car leaves the parking, also sends information to the server. An UML deployment diagram for car sharing scenario is shown in Figure  21. The A2Nets gateway consist of components for both M2M service gateway and M2M overlay communication gateway as is shown in Figure  22. The M2M Service Gateway acts as an application level translator of messages between M2M capillary Networks to Overlay Communications protocol. For example, the messages from CANBUS and USB modules (NFC, GPS) needs to be translated to application level messages in formats applied by the back-office server. The M2M overlay communication gateway facilitates communication with all the devices of the system in a virtual network. For this purpose, the Communications Gateway establishes a Layer2 Tunnel to a Virtual switch through IP/SSL, similarly to OpenVPN Layer2  [74]  and studies and definitions of L2VPN Working Group  [75].
The goal was to publish sensor data for multiple users and provide a way for controlling them. The challenge was that the devices didn't understand any network protocol. Therefore, M2M Gateway is used for transforming sensor data to the format applicable for XMPP communication overlay, and delivering this data trough overlay network to the XMPP back-office server. The first steps of connecting and creating the device metadata are shown in Figure  26. Mobile M2M client devices need at least one static server to connect to. Here we refer this static central point as XMPP back end server, which needs a static DNS-name or a static IP-address for clients to be able to utilize it. The back end server also provides most of the core communication services that are used by the client devices in order to communicate and interact with each other.
Recently a new recipe for developing and deploying real-time systems has become increasingly adopted in the JET tokamak. Powered by the advent of x86 multi-core technology and the reliability of the JET's well established Real-Time Data Network (RTDN) to handle all real-time I/O, an official Linux vanilla kernel has been demonstrated to be able to provide realtime performance to user-space applications that are required to meet stringent timing constraints. In particular, a careful rearrangement of the Interrupt ReQuests' (IRQs) affinities together with the kernel's CPU isolation mechanism allows to obtain either soft or hard real-time behavior depending on the synchronization mechanism adopted. Finally, the Multithreaded Application Real-Time executor (MARTe) framework is used for building applications particularly optimised for exploring multicore architectures.
In the past year, four new systems based on this philosophy have been installed and are now part of the JET's routine operation. The focus of the present work is on the configuration and interconnection of the ingredients that enable these new systems' real-time capability and on the impact that JET's distributed real-time architecture has on system engineering requirements, such as algorithm testing and plant commissioning. Details are given about the common real-time configuration and development path of these systems, followed by a brief description of each system together with results regarding their real-time performance. A cycle time jitter analysis of a user-space MARTe based application synchronising over a network is also presented. The goal is to compare its deterministic performance while running on a vanilla and on a Messaging Real time Grid (MRG) Linux kernel.
I. INTRODUCTION I N the past, real-time requirements meant that a real-time Operating System (OS) had to be used. The ratio between resource availability and demand was very low, i. e. only single-cored CPUs were available to do all the work which included servicing hardware interrupts and scheduling tasks and application threads concurrently. Undoubtedly, and in this situation, priority is the essence driving deterministic behaviour. Linux itself already implements two real-time priority based schedulers, fifo and round robin, but lacks other features such as mechanisms for prioritising interrupt service requests. Over the years, thanks to the effort of a dedicated community, many real-time friendly features such as nearly full kernel preemption capability and high resolution timers have gradually made their way into the Linux kernel.
More recently, the ever growing number of CPUs/Cores in x86 machines has dramatically increased the ratio between resource availability and demand thus motivating the investigation of plain Linux based solutions for real-time applications. This work is focused on the configuration of Linux based systems conforming to real-time requirements and is organised as follows: section II introduces the JET's real-time infrastructure and contextualises the use of the MARTe framework. In section III details are given on how plain Linux can be configured to conform to real-time requirements in multicore architectures. Then section IV introduces the Linux/MRG kernel distribution and presents comparative results on the deterministic performance of a user-space application running on Linux and Linux/MRG.
An important spin-off of the JET's distributed control philosophy is the MARTe software framework for real-time systems  [11]. Just like so many other products at JET, the MARTe framework is the result of nearly two decades of experience in designing and building software for real-time systems. MARTe is a C++ multi-platform framework for the development of modular and highly configurable real-time applications. At its core is the BaseLib2 library. This library implements a layered API spanning basic low level (semaphores, mutexes, threads, filesystem interaction, high resolution timers, etc) to high level functionality such as messaging, http services and configuration parsing. It is very complete, optimised for realtime tasks and presently supports the Linux, Linux/RTAI, VxWorks, Solaris, Windows and the MacOSX OSs.
Examples of the aforementioned diversity of MARTe based applications deployed at JET  [12]  are the vertical stabilisation system (Linux/RTAI)  [13] , the current controller of the error field correction coils (VxWorks)  [14] , the real-time protection sequencer (VxWorks)  [5] , the vessel thermal map (Linux)  [15] , the wall load limiter system (Linux), and the hard X-ray and gamma-ray profile monitor (Linux)  [16]. The merits of the MARTe framework made it become, in the last few years, increasingly adopted and developed  [17]  by the magnetic confinement fusion community in europe  [18]. It is also used in the ISTTOK  [19] , COMPASS  [20]  and FTU  [21]  tokamaks and under consideration for ITER's fast plant system controllers  [22]. One of its main strengths is that it allows application development, testing and debugging in non real-time environments and consequent online deployment without code changes because all the OS dependent functionality is abstracted and, therefore, transparent to the developer.
Development, testing and commissioning time is minimised. Applications can also be developed in user-space (e. g. Linux) and deployed in kernel-space (e. g. Linux/RTAI or VxWorks) seamlessly. Being multi-threaded and particularly optimised for exploring multicore architectures in a manageable and configurable way, dealing with the demands of modern real-time programming, e. g. using mutex priority inheritance and real-time schedulers, MARTe is not surprisingly the framework of choice for building high performance systems.
III. CONFIGURING LINUX FOR REAL-TIME Misconceptions often occur while trying to establish the concept of a real-time system. A real-time system is not about speed, a real-time system is about guaranteeing that timing constraints are met. And those constraints are a function of the system's requirements thus, unique to each system. As an example, the JET's plasma shape controller  [2]  reads magnetic measurements, determines the plasma shape, performs sanity and limits checks and acts on 9 circuits, all within 2 ms, while the vertical stabilisation system executes every 50 /xs. At JET, 1990's Digital Signal Processor (DSP) based realtime systems have been traditionally replaced by VME crates hosting PowerPC processor boards running the VxWorks OS. This approach was especially adopted for fast controllers and diagnostics with hard wiring requirements.
Recently, the need to upgrade and build new systems, mainly to cope with the challenges presented by JET's new metallic wall, has motivated a reflection on the development and deployment paths and operation of some of the already existing systems. Furthermore, building on the experience of developing and testing MARTe based applications in Linux systems, the sole requirement for RTDN based I/O, the vast availability of debugging and profiling tools, the size and dedication of Linux's support community and the attractiveness of it being not only free but also open-source, motivated the investigation of its real-time capability for user-space applications. Some of the reasons why developing user-space real-time applications is more convenient than kernel-space ones are: • in kernel-space basic user-space abstractions such as sockets are not available; • because there is no memory protection, a bug in kernelspace code often means a total freeze of the entire system (and a power cycle); • developing, profiling, debugging, testing and diagnosing in kernel-space is much more lengthy and difficult because tools are scarce and, again, there is no memory protection mechanism.
On the other hand, having an application running in kernelspace does eliminate the context switching overhead between both spaces thus having it closer to the hardware and the scheduler at all times, in principle, with lower latency. In single core CPUs IRQ latency is roughly of the order of tens of microseconds and user-space process latency is of the order of tens of milliseconds depending on the CPU speed. Results presented in  [23]  show comparable latency measurements for a kernel-space task, under no load conditions, running on plain Linux, VxWorks, Linux/RTAI and Linux/Xenomai. In this work the focus is not so much on the average latency itself but rather on the deviation from the average, the jitter, which is a measure of a system's determinism. For example, a system that takes 10 ± 9 s to respond to an external event is surely not considered to be deterministic while another system taking 10±0.
1 s might be. The former has an average relative jitter of 90% while the latter's 1%. Five aspects were carefully taken into account when trying to configure a Linux system for real-time performance: BIOS setup, kernel setup, services configuration, thread affinity and IRQ affinity, all discussed below. Furthermore, systems were built without a swap partition to avoid thrashing upon page faults. A gentler approach would be just to lock the process's local memory space into RAM 1 to prevent paging to the swap area but that does not guarantee that other processes cannot swap to disk, thus creating extra load. Details of the aforementioned individual aspects follow below.
IV. DETERMINISTIC PERFORMANCE COMPARISON OF A USER-SPACE APPLICATION RUNNING ON A VANILLA AND ON A LINUX/MRG KERNEL In this section, the determinism of a user-space application synchronised on an external asynchronous event, is evaluated when running on top of a vanilla and a Linux/MRG kernel. The Linux/MRG kernel was chosen as a term of comparison because it is presently under evaluation by ITER and because it allows to run the exact same user-space application that also runs on a vanilla kernel.
A. The Linux/MRG Kernel The Linux/MRG kernel  [25] , originally from Red Hat and largely inspired by the popular real-time patch (see https://rt. wiki. kernel. org), is specified to provide enhanced determinism to a Linux system. Its major practical enhancement, when compared to a (properly configured) vanilla kernel and from the authors' point of view, is the ability to prioritise IRQ handling by deferring the bulk of the task to ordinary kernel threads. Clearly such flexibility is crucial in case of multiple tasks competing for scarce resources.
B. Apparatus The tests presented here aim to assess the deterministic behaviour of a user-space MARTe based application synchronising on an external event, in this case, the arrival of a network packet. Various conditions have been combined to try to establish the operational boundaries of such a system. In particular, tests were done exploring both multi and singlecore architectures with both switched and direct network connections with and without simulated stress load. The test system is a x86 64bit PC with a 3GHz AMD Phenom(tm) II X4 955 Processor on a Gigabyte Technology GA-MA785GM-US2H motherboard with an onboard ethernet NIC and a FORE PCA-200E PCI based ATM NIC. The standard Linux ATM kernel driver module is used in conjunction with a user-space socket based implementation for ATM I/O.
The distribution of choice is Scientific Linux 6. 2 (based on Red Hat Enterprise Linux) running the 3. 0. 9-rt26. 46. el6rt. x86_64 kernel in MRG and vanilla versions for comparison. The base setup used is shown in Fig. 1. The ATM producer publishes a datagram every 2 rns. This locally synchronised system ensures the datagram is sent with a worst case absolute jitter < 5 /xs and an average absolute jitter of 25 ns. In the system under test, the execution of each real-time cycle is triggered by the arrival of this datagram. A third (so called disturber) system is introduced to assist in load stress testing. It can flood the system under test with ethernet ICMP ping requests as well as simultaneously launching (recursively via ssh) disk usage summary (du /) commands. These cause high CPU process and IRQ handling loads on the test system.