Time Triggered Networks: use in space 2015 CCSDS spring SOIS Plenary 23 March 2015 Glenn Rakow/NASA-GSFC

Contents Critical Vehicle Networks (CVN) or Deterministic Networks (DN) what does CVN? Fault tolerant vs non-fault tolerant DN application space CVN (DN) BOF purpose? describing new subnetwork services? Or are this a fundamental different type of data link,,not a service that any protocol may implement (at least easily without extensive modification) Fault tolerant Time-Triggered (TT) protocols – How are they different than other non-fault tolerant? What do TT protocols enable –TTA

CVN, DN Critical Vehicle Network (CVN) – what are the characteristics of a CVN? Deterministic Network (DN) – different methods on how to do accomplish and each method has different fault tolerance (or none at all) i.e. software schedule for master/slave transactions over Mil-Bus i.e, Time Triggered Protocol – no bus master – global time is maintained by collection of nodes

CVN, DN Application Space Crew-rated missions and robotic mission have very different requirements for CVN or DN Crew-rated mission have safety critical requirements that require “fly- through” faults/failures (fail operate) that are met through availability computing (multiple hot computers operating synchronously) Robotic mission do not have safety critical requirements Does it make sense to use the same protocol for both crew-rated and robotic missions? Many advantages for robotic missions in composability (foster reuse and therefore decrease development and integration time)

CVN (DN) BOF purpose? Seems that impetus of BOF is to address the crew-rated requirements Or is it meant for robotics as well (very different requirements)? Protocols already exist that serve both mission spaces Is purpose of BOF to to add services to subnetwork layer to account for DN (different services depending upon fault tolerance requirements)?

Fault Tolerant Time-Triggered Protocols Different class of DN protocols used for safety critical CVN applications (e.g., Flexray, TTCAN, SAFEbus, TTP/C, TTE) Two that currently stand-out as top contenders Standardized under SAE AS6802 – time triggered Gigabit Ethernet – used on Orion AS6003 – Time triggered protocol slash C – used for control surfaces for some regional jets TT protocols implement special services to ensure fault masking, i.e., Schedule Dispatch – message dispatch static schedule generated off-line for each component Clock synchronization – no time master Start-up Service – synchronize components (cold start or integration/reintegration) distributed algorithm so as to not rely on any one component External synchronization – allows onboard comm. to integrate to external time source, i.e, GPS Clique detection and resolution – unintended scenario where subset of components synchronize within the subset but not over subset boundaries Membership – low level diagnosis that continually monitor system’s health state, which nodes are present due to permanent/transient failures Integrity – bus guardian to protect against babble idiot, and end-to-end arguments Availability – redundancy management of communication channels

What do Time-Triggered Protocols Enable Time Triggered Architectures (TTA) – provides a computing framework for dependable distributed embedded systems Real time application decomposed into cluster(s) of nodes and a fault tolerant global time base generated of know precision at each node Time based used to specify interfaces among nodes 2 phase design approach – architecture design and component (node) design Architecture design phase – interactions among distributed components (and interfaces) in value domain and time domain fully specified Component design phase – Implemented taking these interface specifications as constraints For human-rated missions, safety critical application Availability computing for “fly-through” faults For robotic missions, distributed computing, faster development and integration times, better FDIR Using fault tolerant TT protocols along with time-space partitioned OS and software components

TTP/C vs. TTE Have different performance domains TTGbE is higher performance and higher SWaP Orion (crew-rated domain) TTP/C is lower performance and lower SWaP Crew-rated domain Robotic domain Both should be able to exist without proper layering of architecture Other protocols like Milbus, SpaceWire and SpaceFiber can implement DN services but with lower fault tolerance