Engineering topics

Driscoll, Kevin R.

Publications and source records attributed to Driscoll, Kevin R..

8 records

NASA NTRS2017

Cyber Safety and Security for Reduced Crew Operations (RCO)

NASA and the Aviation Industry is looking into reduced crew operations (RCO) that would cut today's required two-person flight crews down to a single pilot with support from ground-based crews. Shared responsibility across air and ground personnel will require highly reliable and secure data communication and supporting automation, which will be safety-critical for passenger and cargo aircraft. This paper looks at the different types and degrees of authority delegation given from the air to the ground and the ramifications of each, including the safety and security hazards introduced, the mitigation mechanisms for these hazards, and other demands on an RCO system architecture which would be highly invasive into (almost) all safety-critical avionics. The adjacent fields of unmanned aerial systems and autonomous ground vehicles are viewed to find problems that RCO may face and related aviation accident scenarios are described. The paper explores possible data communication architectures to meet stringent performance and information security (INFOSEC) requirements of RCO. Subsequently, potential challenges for RCO data communication authentication, encryption and non-repudiation are identified.

Communications↗

NASA NTRS2013

Stacked Transformer for Driver Gain and Receive Signal Splitting

In a high-speed signal transmission system that uses transformer coupling, there is a need to provide increased transmitted signal strength without adding active components. This invention uses additional transformers to achieve the needed gain. The prior art uses stronger drivers (which require an IC redesign and a higher power supply voltage), or the addition of another active component (which can decrease reliability, increase power consumption, reduce the beneficial effect of serializer/deserializer preemphasis or deemphasis, and/or interfere with fault containment mechanisms), or uses a different transformer winding ratio (which requires redesign of the transformer and may not be feasible with high-speed signals that require a 1:1 winding ratio). This invention achieves the required gain by connecting the secondaries of multiple transformers in series. The primaries of these transformers are currently either connected in parallel or are connected to multiple drivers. There is also a need to split a receive signal to multiple destinations with minimal signal loss. Additional transformers can achieve the split. The prior art uses impedance-matching series resistors that cause a loss of signal. Instead of causing a loss, most instantiations of this invention would actually provide gain. Multiple transformers are used instead of multiple windings on a single transformer because multiple windings on the same transformer would require a redesign of the transformer, and may not be feasible with high-speed transformers that usually require a bifilar winding with a 1:1 ratio. This invention creates the split by connecting the primaries of multiple transformers in series. The secondary of each transformer is connected to one of the intended destinations without the use of impedance-matching series resistors.

Driscoll, Kevin R.↗

NASA NTRS2013

Application Agreement and Integration Services

Application agreement and integration services are required by distributed, fault-tolerant, safety critical systems to assure required performance. An analysis of distributed and hierarchical agreement strategies are developed against the backdrop of observed agreement failures in fielded systems. The documented work was performed under NASA Task Order NNL10AB32T, Validation And Verification of Safety-Critical Integrated Distributed Systems Area 2. This document is intended to satisfy the requirements for deliverable 5.2.11 under Task 4.2.2.3. This report discusses the challenges of maintaining application agreement and integration services. A literature search is presented that documents previous work in the area of replica determinism. Sources of non-deterministic behavior are identified and examples are presented where system level agreement failed to be achieved. We then explore how TTEthernet services can be extended to supply some interesting application agreement frameworks. This document assumes that the reader is familiar with the TTEthernet protocol. The reader is advised to read the TTEthernet protocol standard [1] before reading this document. This document does not re-iterate the content of the standard.

Driscoll, Kevin R.↗

NASA NTRS2013

Investigating System Dependability Modeling Using AADL

This report describes Architecture Analysis & Design Language (AADL) models for a diverse set of fault-tolerant, embedded data networks and describes the methods and tools used to created these models. It also includes error models per the AADL Error Annex. Some networks were modeled using Error Detection Isolation Containment Types (EDICT). This report gives a brief description for each of the networks, a description of its modeling, the model itself, and evaluations of the tools used for creating the models. The methodology includes a naming convention that supports a systematic way to enumerate all of the potential failure modes.

Hall, Brendan↗

NASA NTRS2012

Modeling and Analysis of Mixed Synchronous/Asynchronous Systems

Practical safety-critical distributed systems must integrate safety critical and non-critical data in a common platform. Safety critical systems almost always consist of isochronous components that have synchronous or asynchronous interface with other components. Many of these systems also support a mix of synchronous and asynchronous interfaces. This report presents a study on the modeling and analysis of asynchronous, synchronous, and mixed synchronous/asynchronous systems. We build on the SAE Architecture Analysis and Design Language (AADL) to capture architectures for analysis. We present preliminary work targeted to capture mixed low- and high-criticality data, as well as real-time properties in a common Model of Computation (MoC). An abstract, but representative, test specimen system was created as the system to be modeled.

Driscoll, Kevin R.↗

NASA NTRS2012

Hardware efficient monitoring of input/output signals

A communication device comprises first and second circuits to implement a plurality of ports via which the communicative device is operable to communicate over a plurality of communication channels. For each of the plurality of ports, the communication device comprises: command hardware that includes a first transmitter to transmit data over a respective one of the plurality of channels and a first receiver to receive data from the respective one of the plurality of channels; and monitor hardware that includes a second receiver coupled to the first transmitter and a third receiver coupled to the respective one of the plurality of channels. The first circuit comprises the command hardware for a first subset of the plurality of ports. The second circuit comprises the monitor hardware for the first subset of the plurality of ports and the command hardware for a second subset of the plurality of ports.

Driscoll, Kevin R.↗

NASA NTRS2009

IEEE 1394 Hub With Fault Containment

This innovation is designed to prevent a single end system communication node from negatively influencing the whole system s behavior so that the network system can still operate if an end node is faulty. Placing a hub (star) in the middle of the system prevents propagation of critical control information that other end systems would react to, like block reset messages.

Paulitsch, Michael↗

NASA NTRS2009

Hardware-Efficient Monitoring of I/O Signals

In this invention, command and monitor functionality is moved between the two independent pieces of hardware, in which one had been dedicated to command and the other had been dedicated to monitor, such that some command and some monitor functionality appears in each. The only constraint is that the monitor for signal cannot be in the same hardware as the command I/O it is monitoring. The splitting of the command outputs between independent pieces of hardware may require some communication between them, i.e. an intra-switch trunk line. This innovation reduces the amount of wasted hardware and allows the two independent pieces of hardware to be designed identically in order to save development costs.

Driscoll, Kevin R.↗