Presentation is loading. Please wait.

Presentation is loading. Please wait.

BioNet Middleware BioServe Space Technologies UC-Boulder

Similar presentations


Presentation on theme: "BioNet Middleware BioServe Space Technologies UC-Boulder"— Presentation transcript:

1 BioNet Middleware BioServe Space Technologies UC-Boulder
BioNet Executive Summary Presentation Kevin Gifford, Sebastian Kuzminsky, Shea Williams, Bill Kalinowski, Marek Sotola BioNet Middleware BioServe Space Technologies UC-Boulder CCSDS Fall Meetings, October 2, 2007

2 Presentation Summary Purpose: Present and refine the BioNet Product Roadmap with specific input and guidance from NASA stakeholders (BioNet v2 design effort for the NASA Phase II STTR) Middleware “frameworks” ease software development Provide defined development framework and operational infrastructure Ensure conceptual integrity Ease flight certification process BioNet can help: LAT: Provide device driver/application development framework and data integration of LAT devices, networks, applications C3I: BioNet is one possible instantiation of the C3I data intergration architecture ISS: JSC-EV RFID DTO; JSC-EB MEC/SSCs CHeCS support HRP: Groundside and flightside medical devices for crew health assessmen Ground and Space Operations communities by unified data integration system Our onboard ISS assets (CGBA-4, CGBA-5) and Remote POCC provide TRL advancement opportunities in an operationally-relevant environment BioNet goal: reliable, flight-certified, COTS-available software BioNet software licensing is free to NASA No software acquisition costs

3 BioNet Team / BioServe Space Technologies / Brief Synopsis
BioNet Phase I NASA STTR awarded January 2006; Phase II awarded July 2007 Integrate disparate devices, heterogeneous networks into common data integration framework Involved with CCSDS standardization activities since 2004 (important for international activities) BioServe Space Technologies, UC-Boulder NASA Research Partnership Center (RPC) from 1991 – 2006 Has flown 20 sortie and 6 ISS missions (CGBA, PGBA payloads) 18 Shuttle sorties; 2 to Mir; 6 to ISS CGBA-2 payload launched on STS 112 (10/07/02 launch) (returned Aug 2007; 5 yrs!) CGBA-4 payload launched on ISS 12A.1 (12/14/06): currently on-orbit CGBA-5 payload launched on ISS 13A.1 (8/8/07); currently on-orbit BioNet middleware, and BioServe Communication Stack, on CGBA-4, CGBA-5 payloads Since STS-77 (1996) the BioServe Communications Stack (BCS) has flown on all missions First developers to fly Linux on the Shuttle and on the ISS Flight proven for a decade and at TRL 9 Provides uplink commanding and automated, efficient receipt of flight telemetry to groundside Implements a message and file based store-and-forward transmission system for improved handling of asymmetric, high-BER, intermittently-connected communication links (point-to-point delay tolerant data transmission)

4 BioNet Fundamental Architectural Qualities
Feature Benefit Data interoperability Data from disparate data-producing sensors, controllers, voice, and video can be stored, transported, and consumed by applications by a single system. Multi-vendor solution set Multi-vendor hardware (instrumentation, controllers, radios, etc.) can be considered for the engineering solution. Non-proprietary (open) as well as proprietary solutions can both be considered. Independent development Provide framework for independent development of (1) software to interface with hardware devices and (2) client applications that can make use of any piece of system data for decision-making. Mobility Provide for untethered mobility of sensors, instrumentation equipment, communications devices, and personnel for maximum productivity. Heterogeneous data networks Allow for interoperable use of differing RF and wired technologies [RFID, IEEE (RuBee), (Wi-Fi), (Bluetooth), (ZigBee), (Wi-Max), (WRAN); IEEE 802.3, IEEE 1394, etc.] for maximum flexibility. Scalability System architecture should be distributed and modular. Prevents single-point failures, facilitates upgrades, and decomposes complex systems into manageable components with defined responsibilities. Endpoint re- programmability Allow for endpoint devices (sensors, radios, etc.) to be selectively chosen and dynamically reprogrammed to upgrade functionality while maintaining nominal operation of the control system. Add-on or retro-fit activities Facilitate the late or retro-fit addition of additional sensors, controllers, and communications equipment to add additional required functionality as test and verification activities impose new requirements.

5

6 BioNet Phase I: Centralized Message Broker

7 BioNet Phase II: Distributed Message Bus Architecture

8 BioNet on ISS: Controls CGBA payloads; external device control
Command and control CGBA-4 NAG SDR sdr-hab

9 BioNet Bedrest Study (Human rated deployment)

10 Human-rated Deployment: BioNet-Bedrest results
Patient #1 Patient #2

11

12 BioNet Phase II Technical Objectives
Transition from a centralized message broker architecture to: “a highly-scalable, decentralized, asynchronous, pub/sub message bus” Use voice and video streams as a design driver for architecture. Support the integration of heterogeneous devices and networks into a unified command and communications system. (Phase I original goal). Implement transport delivery vector concept to support different transport mechanisms for the network (AMS, DTN, NAG, multicast, etc.). Integrate DTN for support of intermittent, asymmetric, interplanetary communications. Provide automated database synchronization mechanisms that synchronize data stores as BioNet nodes move dynamically in and out of the network. Advance development framework to facilitate ease of “client” software composition and integration by independent developers. Support IP multicast to optimize network communication efficiency. Provide C3I-compliant services including, but not limited to: security, compression, QoS, and Information Architecture (I/A).

13 End / Demo / Discussion

14 Discussion / Advice from NASA Stakeholders
Technical objectives Important design drivers Strategies for building visibility and advocacy (Level 2 / Level 4) Hardware development BioNet-IMA with Honeywell AMS integration Information Architecture C3I Command and message exchange (XTCE, Vol. 4 and 5) Michelle Schneider, MSFC DTN interaction with JPL International standards & CCSDS The CCA: Demo next summer Communications loops (voice, possibly video, stream management, voice/video recording with C3I-compliant compression, user interface) Phase III customers JSC-EV JSC-EB JPL: DTN JSC-HRP GRC: CoNNeCT, Data Manager C3I? How to gain visibility & advocacy C3I interoperability testing between reference systems CCA?

15 BioNet Data Ontology: Naming Example
In a distributed system with many disparate devices, with the added requirement that both the devices and the data-receiving basestations can all be moved to different physical locations, a properly designed naming scheme is a fundamental requirement As a functional driver, consider the following example: it is required that a crew member be instrumented with a sensor that senses his/her body temperature and that the crew member is allowed to freely move between different functional volumes There are various kinds of objects that are communicated and referred to in the HABs, in the HAB/NAG interface, in the NAG, in the NAG/Client interface, and in the Clients (the applications). The objects are: A HAB A Node A Resource The NAG has a list of all the HABs and each HAB has a list of its nodes. Talk through these bullets to set context for the Naming and Mobility example.

16 Hab-Type.HAB-ID.node-ID:node-service
BioNet Data Ontology: Naming Example Hab-Type.HAB-ID.node-ID:node-service Each HAB is identified by two strings: a HAB-Type and a HAB-ID The HAB-Type specifies what kind of network and protocol the HAB uses to communicate with its nodes on, for example “zigbee” All HABs that use a particular kind of communication protocol have the same HAB-Type. The HAB-ID identifies which network of the particular HAB-Type, e.g., ”destiny” Joining the HAB-Type and the HAB-ID with a dot produces the HAB name, for example “zigbee.destiny” A HAB name uniquely specifies a particular HAB, which is connected to a particular (e.g., sensor) network Each node is identified by what HAB it connects to, and by its Node-ID The Node-ID is a string chosen by the HAB which uniquely specifies a particular node, to a particular HAB Joining the HAB name and the Node-ID with a dot produces the Node name, which is a globally unique node specifier: zigbee.destiny.0:temp

17 BioNet Data Ontology: Naming Example with mobility

18 BioNet Data Ontology: Naming Example, Subscriptions
Each Node has a list of Resources. Resources come in three different types: sensors, actuators, and parameters In addition to specifying complete HAB names, node names, and resource names, we can talk about name "patterns", which are names including wildcards. For example, “zigbee.*.*” is a node name pattern referring to all nodes with HAB-type “zigbee” regardless of location “zigbee.*.*:temperature" is a resource name pattern referring to the temperature sensors of all zigbee nodes Makes it very easy for applications to subscribe to node resources in a groupwise (regular expressions, “regex”, fashion Alex – here we want to emphasize the content of the second bullet where we can use standard string search conventions such as wildcards to access a set of node data. I’d just read the second bullet verbatim…

19 BioNet Data Ontology: Naming Example
BioNet “DevKit”

20 Asynchronous Messaging System, AMS

21 Remote Asynchronous Messaging System (RAMS) Gateway

22 Back-up Slides

23 BioNet/AMS C3I-specific notes
C3I layers 1 – 4 PHY/MAC CCSDS AOS, TM/TC protocols Network: All IP, all the time IP, ICMP, IGMP, BGP, OSPF, GRE Tunneling IntServ, DiffServ QoS IPSec: authentication, privacy, integrity Transport: UDP, TCP, Real-Time Transport Protocol (RTP)

24 BioNet/AMS C3I-specific notes
C3I layers 5 – 7: Data Exchange 3.5.1 Voice exchange 3.5.2 Video exchange 3.5.3 Data exchange C3I Interop Standard Volume 5 3.5.4 File Transfer is via CFDP 3.5.3 Time exchange is NTP 3.6.1 Information Exchange 3.8.1 Command and Control Interoperability Importantly, what should our convergence strategy be in regards to Data Exchange, Information Exchange, and Command/Control Exchange for Interoperability BioNet/AMS/DTN strategic advancement How well does AMS currently align with C3I Data and Information Exchange specifications

25 Software Development Process and Quality Assurance

26 Software Quality Assurance Process

27 Software Quality Assurance Process
Kickoff - Requirements and Specifications Documents Define minimum requirements and interfaces Final requirements document must be documented in writing. Requirements are documented in SGML and “live” with S/W package.  Deliverable: requirements document. Conceptual Design Review (CoDR) Analyze requirements Assess feasibility and complexity of project. Propose concepts and perform trades. Program flowchart (decision tree) is created.  Deliverable: formal presentation and review. Preliminary Design Review (DPR) Addressing of (most) requirements (key elements) for prototype testing. Testing method(s) explicitly identified. Required documentation needs are identified. Review and refine requirements documents as needed.  Deliverable: formal presentation/review, PDR acceptance doc. Software Prototype Testing and Development Problem areas / issues identified and published. Testing results published.  Deliverable: Prototype testing results document. Critical Design Review Addressing of all requirements is mandatory. Includes code review. Integration issues / concerns identified. Clearly identifies all user / hardware / operations interfaces and capabilities not directly addressed as requirements. Initial configuration control document is released.  Deliverable: CDR Acceptance Document. Documentation Baseline Release All user and programmer documentation baselined and available online, including requirements, interface & configuration control documents.  Deliverable: Documentation Acceptance Document. Initial S/W Package Release for User Testing Implement and test (sim., prototype) all software functionality Initial version control started (CVS). Formal Anomaly Report tracking.  Deliverable: Version Control Document. Test Readiness Review (TRR) Software sufficiently tested with prototypes or simulators to ensure high likelihood of successful testing Anomalies from initial testing either addressed or published as known ‘bugs’ Version and configuration control continued.  Deliverable: TRR Acceptance Document. Integrated Verification and Testing (IVT) Modifications as necessary under strict documentation (tracking, buy-off as necessary if interfaces are affected or departure from approved design) Support simulations and tests, software maintenance. Train operations and test engineers and assist as necessary.  Deliverable: IVT Acceptance Document. Bench Review All documents updated / latest revision reflects ‘as built’ state. All anomalies have been addressed and ‘fixes’ have been approved by all stakeholders. Software released for highest fidelity acceptance tests or final science / mission simulations.  Deliverable: All documents updated to latest revision. Flight Readiness Review Verification of all configurable items. All new anomalies have been addressed and ‘fixes’ have been approved by all stakeholders. All documents updated to final revision for flight / customer delivery.


Download ppt "BioNet Middleware BioServe Space Technologies UC-Boulder"

Similar presentations


Ads by Google