Property:Description

This is a property of type Text.

Pages using the property "Description"

Showing 25 pages using this property.

(previous 25) (next 25)

B
BB24.D +	This building block will develop a Context-aware and reasoning platform based on Big Data cloud architecture able to store and process large amounts of data collected by sensors. The platform will apply and adapt the suitable Big Data services for data analytics, essentially based on machine learning techniques, to predict future sensors measurements, to detect anomalies on current sensors measurements, and to optimize processes or configurations of devices.  +
BB24.E +	Implementation of Cloud Computing Services for novel connected mobility applications A number of computing researchers and practitioners have attempted to define Clouds in various ways, here is one of them: "A Cloud is a type of parallel and distributed system consisting of a collection of inter-connected and virtualised computers that are dynamically provisioned and presented as one or more unified computing resources based on service-level agreements established through negotiation between the service provider and consumers.” (Buyya et al. 2008: Market-oriented cloud computing: Vision, hype, and reality for delivering IT services as computing utilities. 10th IEEE International Conference on High Performance Computing and Communications) Coud computing services are then Web services hosted on the Cloud. This building block aims to implement a number of cloud computing services to be used in workpackage 2.6 as shown in the following Figure, where cars, trains, airoplanes and other transportation vehicles collect sensor data and send it to a secure cloud computing platform. The cloud computing platform hosts cloud computing services, which perform business intelligence analytics for a specific purpose. Exemplarily, task 2.6.3 from WP11 will take advantage of the service implemented within this and other building blocks. The service aims to collect car sensor-data from its on board diagnostic interface and send it to a Bluetooth connected single-board computer, which might be enhanced with further sensors. The single-board computer has access to the internet. Aggregated data will be sent to a cloud computing service, which performs analytics. Analytics may add data and information from reliable web-sources and other services. Analytics may be based on data from one or more car sensor datasets. Results may deduce actions to be made or provide statistics and gained insights to the user.  +
BB24.F +	This building block deals with the run-time coordination and synchronization of wireless sensor networks. It is likely that several heterogeneous wireless technologies are used for communication within a vehicle and for vehicle-to-x communication. On the one hand, these wireless technologies use the same frequency band, resulting in cross- technology interference. SCOTT will investigate coexistence mechanisms to maximize the reliability and efficiency of coexisting networks. On the other hand, SCOTT will explore time synchronization mechanisms amongst different access networks that are suitable for industrial settings. For example, one sensor may use the company’s Wi- Fi to connect to the Internet, whereas another sensor belonging to the same logical application may connect via a cellular network to the Internet. If these sensors are used to measure a specific time sequence of values, it is necessary to synchronize their time.  +
BB24.G +	WSN applications with relaxed real-time requirements may perform well with a centralised cloud in the Internet. In such a case, the physical location of a cloud server may in the worst case also be located on another continent. Other WSN applications however, do require lower round trip times and therefore need a distributed cloud, i.e. cloud servers located close to the physical location of the WSN (Mobile Edge Computing, Fog Computing). The edge computing provides also the possibility to filter and pre-process too sensitive data.  +
BB24.H +	In this building block we will develop algorithms for real-time mobility prediction of people and objects as they move through a secure facility, exploiting known roles, access control data, and inference from wireless localization. Secure facilities management depends on the identifying the current and future locations of people and critical objects in the facility. People and objects can be located in space using wireless signals and from live data from access control systems (and also from other data sources and sensors). Future locations and trajectories of people and objects can be predicted from live data, from historic use patterns and from known data on agent roles.  +
BB24.I +	A Semantic Attribute based access control provides the means for different actors having access to different types of information of a system. The former notation of Role-based access control (RBAC) is extended, where "role" is one attribute deciding on the access. As an example, your data of your "heat pump" (energy efficiency) are of interest for a) the house owner, b) the manufacturer, c) the municipalities, d) the maintenance company, e) the person renting the flat, f) the energy distributor. Which data (e.g. statistical) and who has access (attribute: grade of access: monitor, control, configure) might be subject to a security and privacy analysis (attribute: required security level). S-ABAC is seen as tool to provide the functionality, but needs R&I to become usable in a distributed cloud.  +
BB24.J +	Task of this building block is to prepare hardware/software system equipped with additional sensors (e.g. GPS), which collects passenger vehicle data (e.g. diagnostic, usage) over time via standardized vehicle interfaces (for example OBD) and transfers it to a cloud computing service via 3G/4G/5G or via a smart phone paired through Bluetooth (2.1) or connected via WLAN. Designed gateway software allows to securely transfer software from outside into the vehicle and control the update process of the gateway software. It includes a software-based switch to alter trust levels in order to assure that the vehicle driver has full or partiall control and ownership of data shared to the cloud.  +
BB24.K +	Open standards for "smart infrastructure standardisation", e.g. how to configure home networks to comply with the specific requirements of applications This building block is a hardware/software system equipped with additional sensors (e.g. GPS), which records passenger vehicle data over time and in relation to location via standardized vehicle interfaces (for example OBD) and transfers it to a cloud computing service via 3G/4G/5G, or via a smart phone paired through Bluetooth or connected via WLAN. Vehicle data is personal data. Therefore the building block has to enable a trustful provision of vehicle data from in-vehicle systems (ECU’s) to a wireless connection for third party service developers, which can be defined by the vehicle driver. It therefore includes a hardware-based switch to alter trust levels in order to assure that the vehicle driver keeps fully or partially ownership and/or control on data shared to the cloud.  +
BB24.L +	To meet the different requirements of the different IoT industrial domains e.g. smart grids, smart homes, intelligent transport, etc. in terms of data rate, latency, security, availability, etc. this building block will design and implement network slicing, i.e. establishing different network slices for different domain by using SDN (Software Defined Networking), NFV (Network Function Virtualization) and cloud technologies. A network slice shall encompass different access technologies like WLAN, LTE, future access technologies, etc.  +
BB25.A +	Based on an already existing life cycle concept for a WSN for automotive test-beds, this life cycle will be redesigned to include security concepts (authentication, encryption). The redesign includes software, hardware and communication protocols. The design will be implemented in the “Demonstration of ubiquitous testing of automotive systems” (WP12)  +
BB25.B +	This technology building block is made up by an energy efficient transceiver design based on impulse radio UWB technology. An effective system partitioning as well as a related secure architecture concept will be investigated with special focus on energy efficiency and fault resistance. Key IP-blocks resp. sub-systems will be prototyped based on FPGA-technology or test chips. In a second work- stream novel concepts and technologies for secure, resource- optimized, concurrent wireless in-vehicle networking solutions will be investigated. This includes development of a framework for static and dynamic resource optimization, as well as concepts for run-time coordination of concurrent, possibly heterogeneous, wireless in-vehicle networks. Technological synergies between both streams will be exploited as far as possible.  +
BB25.C +	Piezoelectric, solar and thermal energy harvesting for hybrid low- power generator systems with thin-film batteries in the rail domain: to develop a hybrid power generator and storage system using these three sources of energy in order to improve both structural multifunctionality and system-level robustness in energy harvesting.  +
BB25.D +	Reliable electrical energy must be available on sites distributed along the railroad to guarantee the appropriate operation and safety. Unfortunately, a substantial portion of railroad tracks exist in remote areas or certain underground regions in which there is little electrical infrastructure. It seems that a reliable solution requires from different energy harvesters together with an appropriate storage and energy management to integrate the different energy sources using high power harvesting technologies. Choosing the best energy solution (generation & storage) for an specific application based on WSN will be the aim of this BB.  +
BB25.E +	* Synergistic analysis of piezoelectric, solar and thermal (heat sinks) energy harvesting and associated electronic for optimized energy harvesting systems: to optimize a energy harvesting system, both the energy production and electrical (hardware) aspect of the design must be balanced and improved. * Power management Unit: a power management sub- system,“energy harvesting module, which performs the necessary DC-DC conversions while providing maximum power point (MPP) tracking, choosing the highest voltage level from the energy sources provided in the system, controlling the power consumption of the device (with information about the current harvesting conditions) * Software techniques to reduce the energy consumption of low- power devices, Adaptive sensing by exploiting three different approaches: hierarchical sensing, adaptive sampling and model- based active sensing. A. '''Hierarchical sensing''' techniques assume that multiple sensors are installed on the sensor nodes, each characterized by its own accuracy and power consumption, to measure the same physical quantity. In most cases, simple sensors are energy-efficient, but provide a very limited resolution. On the other hand, complex sensors can give a more accurate characterization of the sensed phenomenon at the cost of higher energy consumption. Thus, accuracy can be traded off with energy efficiency. At first, low-power sensors are considered to provide a coarse-grained characterization of the sensing field or trigger an event. Then, accurate, but power hungry, sensors can be activated with measurements used to improve the coarser description. * 1) Triggered sensing: The activation of the more accurate and power-consuming sensors after the low-resolution ones, after some activity within the sensed area has been detected, is referred to triggered sensing. * 2) Multi-scale sensing: A different use of hierarchical sensing consists of identifying areas within the monitoring field that require a more accurate observation. This is obtained by relying on a coarse-grained description of the field with lower accuracy sensors and activating additional high- resolution ones only in areas where their accurate acquisitions are requested. B. '''Adaptive sampling''' techniques are aimed at dynamically adapting the sensor sampling rate by exploiting spatial and/or temporal correlation among acquired data (activity-driven adaptive sampling) and/or the available energy whenever the sensor node is able to harvest energy from the environment (harvesting-aware adaptive sampling). * 1) Activity-driven adaptive sampling: Activity-driven adaptive sampling exploits the correlation (both temporal and spatial) among the acquired data. * 2) Harvesting-aware adaptive sampling: The harvestingaware adaptive sampling techniques exploit knowledge about the residual and the forecasted energy coming from the harvester module to optimize power consumption at the unit level. The approach requires development of models able to characterize the evolution over time of energy availability and the energy consumption of sensor units. '''Model-based active sampling''' consists of building a model of the sensed phenomenon on top of an initial set of sampled data. Once the model is available, next data can be predicted by the model instead of sampling the quantity of interest, hence saving the energy consumed for data sensing. Whenever the requested accuracy is not satisfied anymore, the model needs to be updated, or re-estimated, to adhere to the new dynamics of the physical phenomenon under observation.  +
BB25.F +	A concept for authorization and online security checks in WSNs operated in test vehicles will be developed. Main target is the assignment of sensor nodes to the correct vehicle in case of the operation of test vehicles in close proximity.  +
BB25.G +	Objective: Set-up minimum efforts for application level fault injection, recoverability and fault tolerant scenarios. The basic idea of Fault Injection Techniques309310 is to emulate (is in fact imitate) both hardware and software to better predict the final product quality and reliability. To make models of the hardware, a good representation of the actual hardware is needed. In many cases, emulation can be used to evaluate the software components without the (final version of the) hardware. To create those models, the software requires the following: Representation of hardware models in transfer functions, derived from hardware simulation tools, physics of failure knowledge, Design of Experiments (DoE), or by using the transfer function from previous hardware versions * Models for functional parts of the hardware, to be able to test specific parts only. * Descriptions of interactions between models (dependency/relation) Per today, there is no agreement yet in the community about what availability and reliability means for complex large systems. The proposed dependability tree is published in311. But what are the right tools and methods for validation and verification of large and complex systems?  +
BB26.A +	Define a Reference implementation of an Autonomous Wireless Network System for the Rail infrastructure.  +
BB26.B +	This building block “cloud computing service platform” aims to provide a software development guideline including core functionality software components (a.o. based on standards from W3C), in order to enhance SCOTT members as well as third party companies to build cloud computing services in a standardized way. Therefore the ambition is to provide core functionalities within a reference implementation including examples and documentation in order to assist software developers adopting the concept and start developing fast while avoiding misinterpretations and incompatible solutions. Also security concepts will be tested within this building block. The building block also is responsible for hosting the services within a cloud infrastructure (private or public). [[File:BB3.4.B_overview.png|450px|Cloud computing service platform]]  +
BB26.C +	'''Suggested to be included in BB26.A''' - It will provide service continuity and high availability in the railway domain where it is expected that multi-technological scenarios are present and therefore seamless vertical handover will be required for critical missions  +
BB26.D +	Design a reference architecture that will allow for a convenient infrastructure design and the analysis of security threats in different levels of such architecture  +
BB26.E +	Provide a framework and middleware platform for interoperability between different domains enfocing secure wireless transmission. A middleware architecture wil provide a flexibe framework for application development creating a language for cross-domain reusability and interoperability.  +
BB26.F +	One aspect of SCOTT is the security (and privacy) assessment of system- of-systems. Assessing security, privacy or other properties that give a system its trustworthiness is challenging for the fact that such properties are not easy to measure. Some would say that e.g. security cannot be measured fully. Nevertheless, in practice we always try to calculate the damages of an envisaged attack, and then weigh in with the costs of implementing countermeasures. Therefore, what we often do as system analysts is more or less ad-hoc, and this is understandable because we are trying to “measure the unmeasurables”. This Building Block aims to make explicit into metrics and processes the methods that are normally used to assess various aspects of a system. These would guide an analyst during an evaluation and automate some of the more tedious tasks.  +
BB26.G +	In order to allow authorities or standardization and authorization bodies to evaluate a product with respect to privacy aspects, before attaching a Privacy Label, we need to provide both a methodology and suggest tools to be used in the assessment. Moreover, we need to study closely how the Privacy labels should “look and feel” to the end customers. For this we wil apply interaction design techniques, including surveys and other user analysis techniques. The work has to focus on several aspects: * Privacy Label content which will study what kind of information should the Privacy Label contain and how this information is perceived by the end customer. This work is essential for the end- user adoption. * Privacy evaluation tools are essential in order for a standardization company/authority to be able to evaluate the respective IoT product. Tools that will be investigated in this BB include, complex verification tools, but also simple testing tools and techniques. * Methodology will be designed and prepared for demonstration and application inside the various Use Cases of SCOTT where this BB is applicable. The methodology is something that certification bodies are used with. This includes thorough documentation (and specific to us we will investigate what kind of documentation is needed for Privacy aspects) as well as testing results (for Privacy such testings are not immediately available, and they will have to be investigated part of this BB).  +
BB26.H +	The safe and secure communication of multiple vehicles require dependable wireless communication link. Due to the vehicle mobility the radio propagation conditions is strongly varying leading to non- stationary propagation conditions. In this task a wireless measurement and geometry based real-time wireless-link modelling concept will be investigated and developed.  +
BB26.I +	Define the semantics and ontology features that will allow different entities of the architecture to exchange secure information and minimize attacks.  +

(previous 25) (next 25)