Property:Description

This is a property of type Text.

Pages using the property "Description"

Showing 25 pages using this property.

(previous 25) (next 25)

0
027 +	I tried to show the LinkedIN address of users in the "partner form", but "SHOWFACTBOX" does not show me that LinkedIN is a property. Supported by that Property:LinkedIN has no entries In addition the "read more" is not shown on the partner page, e.g. NVE  +
028 +	The following functionalities failed after we updated to https://its-wiki.no * Josef_Noll - the table showing Lecture, Presentations * figure placement [[File:Screenshot.png|300px|right]] does not move right, showing the "missing" Josef Noll sub-chapters * table formats are not filled  +
029 +	Please add the Maps extension, allowing us to create the maps with all our installations, and replace the its-wiki.no/wiki/DigI:Villages with a real map og all our sites.  +
030 +	on User pages, e.g. [[Josef Noll]] links in the wikitable works. If the picture is not present, that means the User_Picture_URL is not defined, then the links don't work  +
B
BB23.A +	Development and implementation of a WSN, focusing on hardening techniques, fault tolerance and secure communications. The WSN has to be prepared to enhance aspects like dependability, performance and energy consumption. These aspects are related both to hardware and software approaches, considering specific algorithims running in the nodes in devices such as both processors and FPGAs. The node will be designed in a modular way in order to test different approaches in communication and processing. This concept will be extended to upper levels of the network architecture including fault tolerance and resilience characteristics, when needed, and energy awareness when required. The results will be a WSN whose features will be traded by the user in terms of robustness, energy and QoS.this type of design will be particularly demonstrated for the rail use cases  +
BB23.B +	When very different traffic in terms of QoS requirements is agregated in a limited bandwidth link the QoS must be assured for mission critical services (i.e. sensor data with different level of criticity). Mission critical services needs to transmit and/or receive a kind of information affecting, for example, the normal operation of some kind of means of transport (. This attatches to this particular traffic a list of very strong QoS requierements in terms of security and safety like integrity, latency, availability, ... that must be fulfilled at any circumstance. Otherwise, the transport system could be prone to accidents and so the security of the crew, passengers and/or freight is jeopardized. Therefore, advanced prioritization mechasnisms must be performed in the place where bottleneck occurs (ontrack GW or train GW).  +
BB23.C +	Supporting basic security mechanisms such as trust assurance, encryption, signing, authentication, key storage on both virtualized and dedicated HW. This will help the make security features more efficient (power, time, trust) and increase the security level within a WSSN.  +
BB23.D +	The development of safety-critical systems follows well-defined safety standards describing the product development process. However, these standards do not consider security aspects. Therefore, a co-design, co- development and interplay of safety and security will be analysed. Application of common processes for safety and security, e.g. SAE J3061 for security and ISO 26262 for safety (merging of previous BBs “safety level”, “security level”, “safety critical applications for WSNs”)  +
BB23.E +	'''suggest to move to [[SCOTT:BB23.I]]'''<br />Use of satellite safety communications to guarantee the service level requirements (i.e availability, continuity, integrity and latency, etc). It can support data from sensors (or WSN) and typical railway applications, including voice calls.  +
BB23.F +	The use of an additional wireless communication channel, either based on optical signals or on NFC, for authentication and online security checks will be investigated. This additional communication channel enables e.g. secure key exchanges or other additional plausibility checks.  +
BB23.G +	Compared to classical approaches like cryptography, physical layer security is a fundamentally different paradigm, where secrecy is achieved by exploiting the physical layer (PHY) properties of the communication system, such as the nature of fading channels, thermal noise, or interference. While from information theory basic concepts for PHY layer security are already available, their applicability to WNS based on commercial available hardware with all the requirements from specific industrial applications needs to be investigated. Thus in this BB concepts for security checks at PHY level (e.g. RF fingerprinting or making use of node-specific RF impairments like carrier frequency offset) during operation of a WSN, e.g. in a automotive test environment, will be evaluated.  +
BB23.H +	In this building block we will develop algorithms for real-time reconfiguration of secure zones and services in large facilities, bases on wireless access control, localisation and actuation.  +
BB23.I +	In order to reinforce the safety in critical areas of traffic infrastructures, Trustable Warning systems are required to self-discover near vehicles, process relevant information about them and then broadcast the relevant warning information to vehicles in the vicinity. This building block provides the required business logic to allow the previous functionality and the V2I/I2V communications capabilities. This building block will primarily be specified for the railway domain with re-usability for other domains.  +
BB23.J +	Multihop communication is a powerful and cost-effective solution to enable the fast deployment of WSNs, covering large areas or increasing the density of sensing points. It eases the WSN operative removing the need of an infrastructure to support it. But industrial and transportation environments feature highly harsh conditions for these systems, requiring additional efforts to ensure a safety-compliant operation and a basic QoS fulfillment. Communication protocols enabling this ad hoc networking are more complex and require an extended hazards analysis, demanding more robustness, stand-alone unattended operation, and extra coordination to efficiently manage the spectrum scheduling, to recover from errors, to manage the QoS and to ensure the message delivery.  +
BB23.K +	This building block will provide a reliable wireless physical layer to be used in the wireless sensor network. The reliable PHY will provide a fault tolerant wireless transmission between sensors and data concentrator. The data concentrator will receive the information from the application level using a Ethernet or a common interface. The concentrator will translate the information from a wired interface to the wireless sensor system. The reliable wireless system could be used to send critical control data to sensors and actuators replacing the wired system. The use of reliable wireless system to send or receive critical data replacing wired communications will increase the safety of the system, decreasing the complexity of a wired system. With this system, wireless sensors could be located in harsh environments. The BB is related with "safety" because the wireless PHY proposed in this BB will be used to send and receive critical control data from/to a sensor.  +
BB23.L +	Routing and scheduling algorithms, ensuring domain specific constraints (e.g. stock management, planning, profiles) while applies a multi-criteria optimization (e.g. resource performance, ambient impact, safety, energy efficency, waiting/travel times, conditions, etc). This planification can be run off-line, based on the current situation and historical information, but also refresh in real-time, based on adquired information (e.g. transport incidences, delays or dynamic demand). Specifically, from the safety perspective, two lines will be consider: * Geo-fencing and identification of risk situations: collision/run-over risk based on the monitoring of moving elements, work spaces and human movements. * Safe freight: Specific displacement constraints, in terms of maximum speed, scales to perform during the route, vehicle type/loading, avoiding risk itineraries, etc.  +
BB23.M +	The Safety WSN Adapter is a coordinating and bridging technology between the wireless and wired world. It integrates the rail on-board and on-track WSNs into a higher architecture level based on IIoT paradigms, bringing support to safety operation, reliability and QoS requirements. On-board and on-track WSNs, points-of-interest, nearest trains and vehicles (provided with an Onboard Vehicle GW), and POI-local external systems (screens, panels, voice systems, etc.) will use the Safety WSN adapter to integrate in a reliable and safe way.  +
BB23.N +	Common (SW) security library supporting basic and especially lightweight security mechanisms (e.g., encryption, authentication, signing, etc.) in SCOTT also providing an interface to secure HW modules (e.g., TPM, HSM, secure memory, ...) as defined in Building Block “HW supporting security mechanisms”.  +
BB23.O +	Access to data needs to be protected against malicious access. The access might happen during transport or storage between sensors and processing entity, which might be in the cloud. Therefore any communication need to be secured against eavesdropping, modification and impersonation. The building block Security Core will provide a description of available suitable “security tools” that can be utilized for secure authorized access and secure communication. Potential drawbacks, limitations and security issues of the particular approaches are part of the document  +
BB23.P +	The set of tools for utilizing localization/spatial data (e.g. location, direction of the incoming signal, RF signal strength etc.) for object/users authentication and authorization. This block is composed of different localization methods and algorithms and related HW solutions. Moreover, dedicated software solution that utilize this information will be developed, as well as dedicated authentication and authorization mechanismsm. It means that the information about object physical location or the RF signal parameters that are used for its positioning will be used as an additional method to prove his identity and verify its credentials  +
BB23.Q +	Currently two compositions, where a composition is a sequence of railroad carriages that form a unit, are joined by pneumatic, mechanical and electrical connections, doing the operation procedures with trains very difficult, expending a lot of time and personnel. At the same time, the current conections imply an interoperable restricition, because the compositions to be joined must be the same model or at least compatible. Self-configuring adaptive solutions providing plug-and-play features such as Virtual Coupling may solve this issue. In a Virtual Coupling, the compositions run together, as coupled, but without any physical connection, thus trains manufactured by different companies and with different interfaces could be virtually coupled, driven together by the leading cabin and sharing the same traffic slot. In this scenario, Virtual Composition solutions shall require a functional layer where the required business logic to allow different compositions to understand each other will be implemented. All this functional layer will also require V2V Communication support.  +
BB23.R +	Trust Anchor: a (HW) trust anchor dedicated for smart sensors which can be seen as a starting point to establish trust in a WSN/WSSN. Shall be lightweight for smart sensors and strong for gateways/coordinators and of a (wireless) smart sensor network. Trust Indicator: Used to monitor and evaluate the trust within a WSN/WSSN. Realizing the SCOTT Trust Indicator will require a distributed solution were the WSN nodes as well as the WSN coordinator (data sink) continuously monitor the trust within the WSN. The Trust Indicator shows the level of trust-worthiness of the wireless smart sensor network in the setup phase but also dynamically during operation.oordinator nodes.  +
BB24.A +	Open standards for "smart infrastructure standardisation", e.g. how to configure home networks to comply with the specific requirements of applications The main objective of the Building Block “Remote Configuration” is to develop, test and integrate common regarding standards, we have identified: * TR-069 - The CPE WAN Management Protocol (CWMP) * TR-098 - DSLHome Internet Gateway Device * TR-106 - DSLHome Data Model Template for TR-069-Enabled Devices * TR-135 - Data Model for a TR-069 Enabled STB * TR-157 - Component Objects for CWM * PTR-181 - Device Data Model for TR-069 Regarding protocols, we will consider: * 6LowPAN * BluetoothCelluar (GSM/GPRS/EDGE, UMTS/HSPA, LTE) * Hypercat - allows Internet of Things (IoT) clients to discover information about IoT assets over the web * Low-Power Wide-Area Network (LPWAN) * NFC - Near Field Communication * MQTT - a machine-to-machine (M2M)/"Internet of Things" connectivity protocol, http://mqtt.org/Thread (http://www.threadgroup.org/what-Is-thread)WiFi (802.11b/g/n/a/ac/etc) * Zigbee * Z-Wave The building block will start from an implementation of TR-069 in wireless networks, given a set of wireless access points supporting the standard. Using XMPP tunnelling, information of the usage of the wireless connections are forwarded to the cloud infrastructure of EyeSaaS. Through the cloud infrastructure a remote monitoring can be performed to identify bottlenecks of the wireless connection. The specific work will address the extension towards other standards (at least 5 standards from the above list, starting with TR-106 and TR-135) and the remote management of both access points and e.g. mult-media devices. The novel concept of service differentiation based on the requirements of applications for consumer devices is introduced. As of now, customer equipments are based on “best effort” providion, not being able to e.g. perform a hand-over of wireless clients or reserve bandwidth for a certain operation, e.g. voice of Wifi (VoWifi). This technology line will provide technological solutions for the service differentiation, and will provide deployment in the field. The goal is to create a cloud instance of Open Standards for "smart remote management”, and implement a subset of these protocols in existing wireless networks. The technology line addresses infrastructure standardisation, e.g. how to configure home networks to comply with the specific requirements of applications, e.g. voice over Wifi (VoWifi) standards for the management of wireless connections. A series of standards and protocols have been identified being candidates for implementations.  +
BB24.B +	Addressing of sensors and actuators in SCOTT in a non-trivial issue given the fact that different access networks may be used and sensors/actuators should be movable from one network to another. Existing limitations of current access networks (e.g. private IPv4 addresses, limited IPv6 availability, CGNAT in mobile networks, enterprise networks with tight security, non-IP networks) make it difficult to identify nodes. SCOTT nodes should be flexible to deal with these issues in order to be used in as many networks as possible.  +
BB24.C +	Application layer protocols (e.g. SOAP, REST, CoAP, MQTT, etc.) and versatile cloud architectures. Versatile cloud architectures provide a dynamic service based architecture servicing networked control systems (NCS). An infrastructure adaptable to various application areas (such as industrial automation), providing support for fault tolerant, safe, secure and dynamic resource systems. The architecture must provide centralized but also local information processing. Potentially concurrent local sub-structures should be able to operate and be maintained independently.  +

(previous 25) (next 25)