dataesr/scientific-paragraphs-categorization huggingface dataset:
These boards will then become an interesting choice for both general purpose functions and functions with specific needs, even being able to substitute MCUs in most cases, thanks to tools such as virtualisation. Further in-depth analysis will be carried out on this topic in this paper in §7. 3. If we focus on different features, some widespread examples would be the NVIDIA Jetson AGX Xavier  [244]  for High-Performance Computing (HPCs), Qualcomm Gen2/3/4  [245]  for Graphical Processing Units (GPUs) or Mobileye 6-Series  [246]  for AI-based functions relying on Neuronal Network Processing (NPUs). Thus, summing up, there is a wide variety of potential ECUs available from different suppliers, already compliant with legislation and certificates, and even in academic research  [247] -  [249] , that could be used for the new software enhanced automotive systems.
e. , which products will be part of the product line and what are their commonalities and variants). (2) Domain engineering, in which the objective is to design the underlying system architecture by characterising the inter-application reusability and pre-scheduling their data exchanges. Furthermore, in this phase, the system will also produce different test-cases, scenarios, documentation, and specifications for each individual product. Finally, (3) Application engineering, in which the output of the two precedent phases will be analysed, the inter-application conflicts resolved, and the development of the final architecture and applications will be done through the creation of reusable templates that will be further tested and integrated into the architecture, trying to maintain them so that they are reusable for future iterations or projects.
C. NETWORK ARCHITECTURES Given the advances of both E/E (cf. § VI-A) and Software architecture (cf. § VI-B), we now need to adapt the network stack so as to fully profit from the new bandwidth enhancements thanks to the higher presence of Ethernet, the new simple E/E architecture board availability, and to match the requirements necessary to have fault-tolerant databased communication middleware (or Enterprise Service Bus). Thus, in this section we will start by (1) surveying how the network architecture is standardised, by analysing application-level network protocols to be used for this homogeneous data-based communication middleware over IP. After that, (2) we will discuss the rest of the tooling that allows us to enable data-oriented communications over this middleware, which is a key point for a flexible and dynamic abstract communication ESB.
One final positive characteristic of AUTOSAR is the fact that it has already been widely adopted by the automotive OEMs which eases the transition to a software-oriented architecture. However, AUTOSAR has the same problems as the rest of the broker centralised communication protocols, as well as the fact that it does not handle data objects or serialise a method invocation payload. Hence, if we look further into detail in Table  7 , it seems clear that the combination of multiple communication protocols can be useful to cover all the different automotive use cases. To begin, among the communication protocols that include publish/subscribe patterns, the most remarkable solutions would be MQTT, SOME/IP, DDS, AMQP and ROS2. If we try to use the most resource efficient solution, despite security issues, MQTT offers the lowest resource consumption and compatibility for Android, Austosar Adaptive and Linux.
In addition to that, MQTT is a widespread solution in the IT world, which is an advantage when customers are looking for new solutions at a lower price. From another point of view, if what we seek is a solution that is compatible with both the old ECUs and the new ones, SOME/IP, as it's the AUTOSAR solution, is the only one capable of ensuring compatibility with both AUTOSAR Classic and the other Linux-based operating systems. However, SOME/IP is far from being optimal in terms of other criteria, having low security and higher development and maintenance costs than MQTT. From a security point of view, both solutions offer basic authentication, encryption, and TLS techniques. However, other communication protocols like ROS2, AMQP and DDS have stronger additional mechanisms in exchange for a higher resource consumption.
However, if resource efficiency is a priority, WebSocket is the most interesting solution. Nevertheless, this protocol needs low-level knowledge of the infrastructure, which blocks the network abstraction concept of SOA unless an abstraction connection manager is implemented over this network stack at application level. After that, when focusing on security, it is clear that OPC UA is the most adequate solution. However, the development and maintenance costs and the resource consumption of the protocol are higher than the other ones. Finally, as in the case of the publish/subscribe paradigm, SOME/IP is the only fully compatible solution with the AUTOSAR classic and Linux-based ECUs. ✓ ✓ ✓(bidirectional) ✓ ✗ ✗ ✗ ✗ ✗ ✓ ✓ Publish/Subscribe ✗ ✗ ✗ ✗ ∼ ✓ ✓(P2P and Broker) ✓ ✓(P2P) ✓(P2P) ✓ ✓ Fire & Forget ✗ ∼ ∼ ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✓ Paradigm Static subscribe ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ Topology 1-1 1-N 1-N 1-N 1-N N-1-N N-1-N or N-N N-1-N N-N N-N N-1 1-1 Broker No need No need No need No need No need Centralized Centralized/Distributed Centralized Distributed Distributed Centralized Centralized Multicast ✓ ✗ ✗ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ Asynchronous ✗ ✗ ✗ ✗ ∼ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Dynamic discovery ✗ ✗ ✗ ✗ ✗ ✗ ✓(device) ✗ ✓(service) ✓(service) ✓(service) ✓(service) Architecture Network abstraction ✗ ✗ ✗ ✗ ∼ ∼ ✓ ∼ ✓ ✓ ∼ ∼ Payload data ✗ ✗ ✗ ✓(Limited) ✓(3 levels) ✓(3 levels) ✗ ✓ ✓ ✗ ✓ Autosar Classic ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ Autosar Adaptive ✓ ✓ ∼ ✓ ∼ ∼ ✗ ✗ ✓ ✗ ∼ ✓ Linux-like ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ System Android ∼ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ∼ ✓ ∼ TLS/DTLS ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Authentication ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ∼ Encryption ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ∼ Access Control ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ∼ 2) Data-management: Through a data-centric communication middleware As the aforementioned evolution trends of both E/E and software architecture suggest an increasing break in domain boundaries (i.
e. , ADAS, Power-train. ), a democratization of Ethernet as the main transport support, a dynamic and seamless perception of the software location, as well as a steady rise the complexity of deterministic. Whilst deterministic comm. is a key challenge to match real-time constraints of the automotive sector  [332] , something that we will discuss in depth later in § VI-C3, in this section we are going to focus on the migration from static network mapping to more flexible and dynamic data-centric mechanisms. Remember that, in the FCA sub-variants, and specifically in SOA, systems are represented as a set of services that are either data producers, data consumers or both at the same time. Today, as the in-vehicle systems and development processes mostly ECU / signal-based development approaches, the complexity and data maintenance of both signal and bus message databases requires a lot of time and money  [333].
B. DELIVERY Nowadays, software deployment in the Automotive sector is highly conditioned by the place in which this software deployment takes place, with different mechanisms and constraints existing whether it takes place in production after-sales, or in maintenance garages  [422] ,  [423] ,  [424]. Furthermore, this deployment process takes place through different means depending on the size and safety impact of the packages to be installed. On the one hand, software and configurations for small software factory/garage deployment can be deployed physically, through the OBD-II port  [425] ,  [426] ,  [427] , or through the USB port for biggersized packages both in production, garages and after-sales. On the other hand, for all low-to-medium sized packages, this deployment can also be done directly and remotely with Over-The-Air (OTA)  [428] ,  [429] , which is currently being implemented by most Automakers as it allows for the saving of millions of dollars, minimising repair delays, and reducing the environmental impact deriving from update campaigns.
However, even though until now, the OTA update frameworks are not systematically used for all update any size and safety issues they may be caused if dealt with incautiously must be considered, studies continue to show  [1] ,  [430]  that OTA importance will likely keep growing in the near future. In this subsection, we will begin by briefly going through the deployment possibilities and limitations of physical deployment means, -i. e. , OBD-II and USB deployment, as they are already widely used by all automakers and, thus, overly complicated to change due to the economic impact that it would imply. Subsequently, we are going to focus hard on the state of the art of Over-The-Air software delivery, which is currently the main challenge faced by software deployment.
1) Physical software deployment frameworks Even though The standard OBD-II port was first conceived to gain access to on-board diagnostics, it still allows automakers and other third parties to develop software updates, and even software embedded dongles, which interact safely and naturally with in-vehicle systems. Even though these packages that are to be installed rely on, as they also will do for most of the cases both in USB and OTA deployment, certificates, basic encryption libraries and a pre-loaded set of keys to secure this software transaction and prevent most of the attacks  [427] ,  [431]. Physical updates have some interesting capabilities as they allow, prior to having a full on-board system up and running and configured, the deployment of basic software and configuration, including the initial set of proprietary keys, which enables the rest of the software to have a secure update.
Moreover, even though the OBD-II port data rate is considerably low, USB port allows us to bring in big Media file packages  [432] ,  [433] ,  [434] , such as GNSS maps, in an easier way than if we were using unstable OTA connections. It is worth noting that, OBD-II is nowadays considered to be the preferred technology for onproduction software/configuration deployment, since only a really basic set of configurations are deployed in this phase due to time restrictions (cf. Fig. 17 ) and given the economic cost of changing the safety/quality control tooling already implemented and deployed in all factories and garages. Thus, in order for OTA deployment frameworks to be successfully integrated into the chain, they need to preserve, at least for now, the standards allowing the use of pre-existing OBD-IIbased diagnostic/safety tooling.
2) Operating systems Operating systems, similar in many ways to Firmware, but more complex and less hardware specific, are a set of software that normally runs in kernel mode, providing the application developers with a clean abstract set of resources that can be exploited and used to manage hardware resources associated with enhancing the capabilities of the devices. Appearing in the 1950s for mainframes, their evolution and flexibility has led to a complete palette of choices depending on system constraints (processing, memory management, networking. ) and preferences (real-time support, security and safety, power consumption. ). In this part, we will mainly focus on the Operating Systems that are able to run in resource-constrained devices, which therefore excludes classic PC Operating Systems such as Ubuntu or Windows and the server-oriented OSs.
However, the energy consumption of this solution is slightly higher than TinyOS. After that, regarding a cross Linux/Windows environment solution, we can turn our attention to MantisOS. MantisOS is a microkernel-based solution that does not follow the eventdriven programming model it (only allows multi-threading). Adding more security compared with the past two solutions and various semaphores to deal with the inter-thread comm. (which implies higher energy cons. ), MantisOS presents itself as an interesting solution for applications with more sensitive data (or with higher criticality). However, none of these solutions comply with the norms without adding extra security and safety mechanisms. Finally, we have LiteOS, which is the most used Linuxbased solution over sensor nodes. This Operating System was conceived to provide an UNIX-like environment for IoT developers and to supply programmers with familiar programming paradigms such as a hierarchical file system developed using LiteC and a UNIX-like shell.
In this type of OSs, we should focus onQNX Neutrino  [462] , WindRiver VxWorks  [463] ,  [464] , Embedded Linux (uCLinux)  [465] , Android Things  [466]  and Raspbian  [467]. To begin, uCLinux is an open-source Linux-based OS that extends the classic Linux kernel to enable its operation in micro-controllers without MMU (memory management unit). As in the classic Linux, uCLinux follows a monolithic architecture to which you can add different CPU platforms and file systems that are more adapted to embedded solutions. At the same time, uCLinux supports multi-threading programming, a wide set of networking and communication protocols as well as using a priority-based preemptive scheduler to manage call executions. However, the security mechanisms that uCLinux implements are not completely secure and the energy consumption of the Operating System could be lower, despite the kernel sleep mode possibility.
Then we have Raspbian, Android Things and QNX Neutrino, all of which are based on the classic Linux Kernel. Despite their similarity to uCLinux, all these solutions need to have, or benefit strongly from having, an MMU to operate under. Raspbian is a solution conceived for RPi hardware that has lower energy consumption and higher security while operating on their specific boards. However, when it operates over other kinds of hardware, its performance and energy consumption are mostly similar to those of uCLinux. With even safer security mechanisms, we have QNX Neutrino. QNX Neutrino is a solution focused on the security and reliability for the automotive and medical industry. However, this linux-based solution is less optimal in terms of energy consumption, but it is compliant with the automotive ISO 26262 D level without needing any modifications.
Finally, we have the leader of the smartphone market, Android who have presented Android Things to conquer the OS ecosystem of the embedded system by offering the development tools, the wide android store, and the strength of the big Android developing community. This port of Android manages to keep power consumption low, even lower than the solutions that have already been presented, despite the security of the system which was already representative of the Smartphone Android OS. Finally, as the only remarkable non-Linux embedded OS, we have WindRiver VxWorks. Widely used by the aeronautical, automobile and telecommunications industry, this system is an alternative if you need a real-time safe (ASIL D) operating system without an excessively high energy consumption. (3) Automotive Operating Systems.
This solution is based on a rather small micro-kernel that supports multi-threading and includes a preemptive scheduler. Therefore, the small size of the kernel makes this solution very scalable, simple, easy to use, highly portable and with an incredibly low energy consumption. However, the security of this Operating System relies only on a lightweight OpenSSL substitute: WolfSSL, which means it is indirectly adapted to the automotive environment requirements without extra development work. However, with the appearance of the SafeR-TOS extension, it gains ASIL D security and safety precertification, making its adaptation to the automotive industry much easier. In the same scope, we have RIOT which is another open-source non-Linux based OS. RIOT supports many interesting functionalities such as hardware abstraction, interruption handling, memory management, IPC and good reliable synchronisation, performance, scalability, and an energy consumption similar to FreeRTOS.
Tizen was designed and introduced by Samsung for their mobile devices, wearable devices, and smart TVs. Therefore, the energy consumption and multimedia capabilities of the OS are remarkably interesting for the automotive industry. However, as they are not designed for a safe-critical domain, the security capabilities are far from optimal. To sum up, if we look at Table  10 , we can see that most of the operating systems matching both the consumption and security requirements are Linux-based, which helps to decrease the development complexity. For the low-end sensor nodes on the system LiteOS, if real time is not required, FreeRTOS and Autosar Adaptive show themselves to be the most complete solutions. However, due to its compatibility with Autosar Classic and all the current infrastructure, Autosar Adaptive seems like the best choice for, at least, the transition to a more centralised architecture.
3) Software virtualisation Thus, in order to make the installation and development of new applications more flexible, dynamic, reusable, and simple, we usually put the applications over an Operating System, as they are no longer firmware applications but software applications, which is already the case for the Automaker MPU nodes. Even though we usually use firmware for the MCUs due to their restrained resources, there are other possibilities as the micro-kernel OSs presented above in Table  10 , such as RIOT, MantisOS or FreeRTOS. Moreover, when installing the software over an operating system, there are other mechanisms on top of this to increase system flexibility and adaptability even more. The most common way to do this is virtualisation, which presents itself as a technology able to combine or divide computing resources.
Thus, this technique helps to map virtual resources to physical resources and uses the native hardware for computations in the virtual machine. This mapping and the resource management process is managed by a control software called Hypervisor. There are multiple ways to implement HAL virtualisation, however, in this paper, we will focus on the two most widespread: Full-Virtualisation, in which the guest OS are fully independent, both from the rest of the host and guest OSs, and are built either on the top of the physical hardware (a -Type I or Bare-Metal Hypervisor) or on top of an existing OS (b -Type II or Hosted Virtualisation), and (c -) Para-virtualisation, in which the guest OS kernel must  be modified to act as a bridge between the different apps. and the hardware resources. (a) Type I or Bare-Metal Hypervisor.
In Type-I hypervisors, the hypervisor is placed directly over the hardware. It is small as its main task is sharing and managing hardware resources between the different OS running in the machine. The major advantages of this solution are that it achieves a performance at almost 100% of its capabilities and that any existing problem in one of the different guest OS running on the hypervisor will never affect any other guest. We are going to analyse and consider the following as representative solutions to this model,Linux KVM  [483] , VMware ESXi  [484] , XEN  [485]  and Hyper-V  [486]. (b) Type II or Hosted Virtualisation. In Type-II hypervisors, the hypervisor runs over a host Operating System instead of directly over the hardware. Even though it runs over a host OS, the hypervisor can support other OSs above it.
(ii) Software delivery pipelines. First, with the enhanced networking capabilities of vehicles, software delivery faces a new revolution, needing to integrate OTA within their classic software management cycle, and then focusing on how to ensure the safety, security and data authenticity becomes of vital importance, as the scope of this mechanism and its attack surface are both enormous is huge  [445]. Secondly, further research is needed on software deployment so as to, first of all pick the appropriate Operating system and, secondly, choose the right installation method that will favor flexibility, isolation. [507]. Thirdly, testing faces many open issues with regard to dynamic certification and the testing process itself that also needs further work  [521]. Finally, additional research needs to be done on how to orchestrate, both efficiently and dynamically, the in-vehicle applications depending on the software context and also the nearby users  [533].
same scope, in C. Wang et al. [315]  they propose a Service-Oriented model for heterogeneous MPSoCs, suggesting a new 3-layered hierarchical model, as we can see in Fig. 13. Thus, the three layers are, in order from the furthest from the hardware, to the closest; (1) the Services Layer, which offers an API for deployment, runtime analysis mechanisms, an orchestrator and scheduler and some data collection services, (2) the Servants Layer, which VOLUME 4, 2016 21 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. Citation information: DOI 10. 1109/ACCESS. 2023. 3294256 This work is licensed under a Creative Commons Attribution 4. 0 License. For more information, see https://creativecommons.
This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. Citation information: DOI 10. 1109/ACCESS. 2023. 3294256 This work is licensed under a Creative Commons Attribution 4. 0 License. For more information, see https://creativecommons. org/licenses/by/4. 0/ D. Fernández Blanco et al. : A comprehensive survey on SaaS transformation for the automotive systems 1) Data collection.
[590] , J. Wu et al. [591]  or I. Odun-Ayo et al. [592]  -or in IoT systems -i. e. , M. Wang et al. [593]  or O. Khalaf et al. [594]. Moreover, we can also point out many contributions concerning the form of storage either using the blockchain -i. e. , R. Li et al. [595] or L. Wei et al. [596] -, classic databases -i. e. , C. Gyhorodi et al. [597] or Z. Lv et al. [598] -or non-relational databases -i. e. , S. Bradshaw et al. [599] or J. Yang et al. [600].
Finally, within the same scope, in C. Wang et al. [315]  they propose a Service-Oriented model for heterogeneous MPSoCs, suggesting a new 3-layered hierarchical model, as we can see in Fig. 13. Thus, the three layers are, in order from the furthest from the hardware, to the closest; (1) the Services Layer, which offers an API for deployment, runtime analysis mechanisms, an orchestrator and scheduler and some data collection services, (2) the Servants Layer, which VOLUME 4, 2016 21 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. Citation information: DOI 10. 1109/ACCESS. 2023. 3294256 This work is licensed under a Creative Commons Attribution 4. 0 License. For more information, see https://creativecommons.
Variational Quantum Algorithms are hybrid classical-quantum algorithms where classical and quantum computation work in tandem to solve computational problems. These algorithms create interesting challenges for the design of suitable programming languages. In this paper we introduce Qimaera, which is a set of libraries for the Idris 2 programming language that enable the programmer to implement hybrid classical-quantum algorithms where the full power of the elegant Idris language works in synchrony with quantum programming primitives. The two key ingredients of Idris that make this possible are (1) dependent types which allow us to implement unitary quantum operations; and (2) linearity which allows us to enforce fine-grained control over the execution of quantum operations so that we may detect and reject many physically inadmissible programs.