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.

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

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.