System Architecture Design

More documents

Recommendations

Info

pSHIELDSystem Architecture DesignPUtechnologies. This adapter is in charge of providing (through the pS-NC interface) all the neededinformation to the pSHIELD Middleware adapter to enable the SPD composability of the Node layerlegacy and Node pSHIELD-specific functionalities. Moreover, the pSHIELD Node Adapter translates thetechnology independent commands, configurations and decisions coming from the pS-NC interface intotechnology dependent ones and enforce them also to the legacy Node functionalities through the NCinterface.In order to show a generic model valid both for the pSHIELD Nano, Micro, Personal and Power Nodes,the different Node Layer Innovative SPD Functionalities (i.e. SPD components) are grouped into propermodules containing functional subsets of the Innovative SPD capabilities provided by the pSHIELD Node.In brief, the main modules of a generic pSHIELD Node Adapter are:• pSHIELD Interface, which provides a proper interface to the pSHIELD Network• SPD Node Status, responsible for collecting the status of each individual component, andproviding SPD-relevant parameters and measurements to the Middleware Layer. It also checkson system health status for self-recovery, self-reconfiguration and self-adaptation• Reconfiguration, which performs module or system reconfiguration by demand of the systemSPD Node Status or the Middleware• Dependability, responsible for applying self-dependability at node layer, by detecting problemsrelated to system health status, and starting recovery. It is also responsible for collectingcheckpoints from the remaining pSHIELD Node Adapter modules, and retrieving this informationduring system recovery• Security and Privacy, enforcing system security and privacy at node level, by providinghardware or software encryption, decryption, key generation, firmware protection, etc.• Power Management, module for managing power sources, providing protection againstblackouts, etc.• Node pSHIELD Specific Components, which are the innovative SPD functionalities provided toeach of the Legacy Device Components, such as status and metrics, checkpoint-recovery, etc.Depending on the type of node, application, technology, etc. each of these modules may be implementedwith different pSHIELD SPD functionalities or even be not implemented. More information on each ofthese modules is provided in Section 6.1.1.4.2.The pSHIELD Node may be supported by generic hard boards with CPUs or PICs and FLASH memory,special designed boards, boards with FPGA (partially dynamically reconfigurable or not), etc.Section 6.1.1.4.1 describes some different configuration possibilities for these boards, depending on nodetypes.6.1.1.1 Description of pSHIELD SPD Node Layer Blocks6.1.1.1.1 Node Legacy Device ComponentThis may be any legacy, third-party or of-the-shelf component. Examples are: single or multi-core CPU,network adapter, Input/Output device, sensor, actuator, memory, power device, etc. By themselves, thesecomponents are not SPD compliant, meaning that they don’t expose any capability to the Middleware, andneed the corresponding Node pSHIELD Specific Components to do so.PUD2.3.2Issue 5 Page 68 of 122
pSHIELDSystem Architecture DesignPU6.1.1.1.2 Node pSHIELD Specific ComponentEach Node Legacy Device Component must have a corresponding Node pSHIELD Specific Componentthat provides SPD capabilities. This component is mandatory for each legacy device. However, dependingon node level, some of these capabilities may be optional. The list of capabilities that must or can beprovided to each legacy device component is:• Proxy – providing an interface between the device and the middleware layer, by providing thenecessary elements, such as its functionality, an ID, composability information, etc.• Status – providing the device status to the SPD Node Status through a periodic heartbeat. If anerror is detected in the device, depending on its severity, this specific component may either sendthe error data inside the status information or stop sending the heartbeat. If possible, any actionsfrom this specific component and Device are disabled, preventing error propagation• Checkpoint – the internal status of both the Legacy Device and Specific components are also sentto the Dependability block for checkpointing• Rollback-recovery – on system recovery, the Specific Component should be able to recover thecomponent status, stored at stable storage (SS), and restart it• Self-test – the Specific Component may also perform its own monitoring activities, such asperforming a Power-On Self-Test on the Legacy Device ComponentAll the other modules of the pSHIELD Node Adapter expose the same capabilities.6.1.1.1.3 SPD Node StatusThis block supervises all other blocks at Node level, by collecting their periodic status information. AHeartbeat containing the global layer status is sent to the Dependability block. If one of the blocks fails theperiodic heartbeat with status information or receives an error, the SPD Node Status block also stops itsown heartbeat, and the Dependability Block starts recovery (e.g. by resetting the system).This global status information may also be sent to the overlay layer.The SPD Node Status may also send extended status information to dependability block, for a possiblepost-mortem analysis.All the other blocks at Node layer must send periodic status information to this one. Invalid or inexistentstatus information is considered as block failure.This block may also perform its own monitoring activities, such as performing a Power-On Self-Test.6.1.1.1.4 DependabilityThis block supervises all other blocks at Node level, by collecting their periodic status information. AHeartbeat containing the global layer status is sent to the Dependability block. If one of the blocks fails theperiodic heartbeat with status information or receives an error, the SPD Node Status block also stops itsown heartbeat, and the Dependability Block starts recovery (e.g. by resetting the system).This global status information may also be sent to the overlay layer.The SPD Node Status may also send extended status information to dependability block, for a possiblepost-mortem analysis.All the other blocks at Node layer must send periodic status information to this one. Invalid or inexistentstatus information is considered as block failure.PUD2.3.2Issue 5 Page 69 of 122
Page 1 and 2:
Project no: 100204pSHIELDpilot embe
Page 3 and 4:
Contents1 Executive Summary .......
Page 5 and 6:
FiguresFigure 1 - A generic embedde
Page 7 and 8:
Figure 45 - pSHIELD Security Agent
Page 9 and 10:
MGFMIPSMLNeLNFMRFPNMPNMPSNoLNVMOLOS
Page 11 and 12:
Issue 5Page xi
Page 13 and 14:
pSHIELDSystem Architecture DesignPU
Page 15 and 16:
Page 17 and 18: pSHIELDSystem Architecture DesignPU
Page 19 and 20: pSHIELDSystem Architecture Design3.
Page 31 and 32: pSHIELDSystem Architecture Design
Page 39 and 40: pSHIELDSystem Architecture Design
Page 47 and 48: pSHIELDSystem Architecture Designen
Page 67: pSHIELDSystem Architecture DesignPU
Page 119 and 120:
Page 121 and 122:
show all

System Architecture Design

Create successful ePaper yourself

Delete template?

Save as template?