KOSEN 한인과학기술자네트워크

Reconfiguration of Component Level Control Network Automation Systems Primary Sponsor: Department of Defense Deadline: 4/11/2001 KEYWORDS TECHNOLOGY AREAS: Ground/Sea Vehicles, Materials/Processes OBJECTIVE: To reduce the latency of network reconfiguration in a distributed control infrastructure for component level based automation systems on Naval Platforms. DESCRIPTION: A key parameter governing the cost and performance of a system with reconfiguration capability, such as a communication system with the capability of healing a damaged network, is the latency of reconfiguration (time between failure detection and fix). Different systems have different tolerance thresholds for network communications latencies. The level of redundancy required to ensure small latencies could be cost prohibitive. Healing involves some combination of overloading existing resources and/or marshalling redundant resources. By predicting where damage is likely to occur, one could utilize redundant resources to reconfigure the network in anticipation of the damage event. The objective of this would be to steer traffic away from the predicted damaged network segment. By pre-positioning network resources prior to the damage event, the processing required to determine the appropriate healing path could be reduced to a simple reconfiguration step, thus reducing damage induced latency from the healing process. The system is a component level or device level automation infrastructure for Navy Shipboard automation, using the ANSI 709.1 control protocol. The system employs a dependable network topology consisting of a partial mesh of network rings. Each node in the network is attached to a wire ring and the rings are connected with routers. There are redundant routers on each ring. Under normal operation the redundant routers are off-line. In the event of damage, parts of each ring may become fragmented and therefore no longer able to talk to other parts of the ring or to neighboring rings. A concept called "network fragment healing" re-configures the routers to "heal" the network It reconnects the fragments by routing traffic through neighboring rings. This "healing" may include bringing some of the redundant routers on-line and changing the communication parameters of the nodes to reduce the traffic load. Criteria used for rerouting include load balancing and prioritization of traffic based on critical services. The logic for doing the reconfiguration is held by sentinal nodes. Reconfiguration takes time. Sentinals search the network to determine the extent of damage and paths to heal, and re-configure the routers and nodes by sending messages. While the reconfiguration is underway network traffic may be interrupted. Simple approaches to reconfiguration treat all traffic and all nodes as equivalent. The logic for reconfiguration gets more complex as more details about the node functionality get used. At some point it becomes difficult to re-configure correctly without more comprehensive knowledge such as might be provided by a model. Moreover in the case of pre-hit configuration, it would be helpful to be able to "predict" the effects of the reconfiguration before attempting to re-configure. Thus a model of the system that determines pre-hit the likely extent of damage, will allow for reconfiguration with reduce latency. Example: Suppose the radar systems predicts a missile will hit the ship and damage compartment A. In compartment A are several systems using the component level automation network, i.e. the chill water system and damage control sensors. Under normal operating conditions the combined traffic of all the devices in compartment A uses 25% of the bandwidth. After the hit it is expected that the damage control sensors will use 75% of the bandwidth (the damage will generate a lot of alarms and damage indications). This will saturate the channel, and drive down the channel efficiency. Damage may fragment the network and cause nodes to be isolated. The chill water system will go into war fighting mode and shed all its non-critical loads. A pre-hit reconfiguration system would, upon reception of the expected hit notification, search for likely healing paths and re-configure the routers before the hit occurs and while the network still has sufficient reserve capacity. In addition the system might reduce traffic by re-configuring the nodes on non critical sensors and actuators by updating monitoring traffic at a slower rate, or not at all for the time required to re-configure after the hit. The time it takes to recover from the damage might be reduced enough so that the capability of the damage control system is not so adversely affected. PHASE I: Given a pre-hit configuration for a component level automation infrastructure, design a model to predict the system state resulting from various damage scenarios, and determine the optimal pre-hit configuration that would minimize disruption of the infrastructure for each such damage scenario. PHASE II: Develop and integrate the model into a demonstration of network fragment healing infrastructure for pre-hit configuration. PHASE III: Refine and enhance the model and pre-hit reconfiguration for integration into a full-scale network. Extend the model to include ship systems built on automation infrastructure. DUAL-USE POTENTIAL: Mission critical or continuous available systems such as process control, security, or transportation are severely impacted by an interruption due to damage, vandalism, or catastrophe. Pre-damage reconfiguration can ameliorate or reduce the total impact on these systems. KEYWORDS: Automation; Network Fragment Healing; Reconfiguration; Latency; Damage Tolerance; Message Traffic DoD Notice: Between January 2 and February 28, 2001, you may talk directly with the DoD scientists and engineers who authored the solicitation topics, to ask technical questions about the topics. The Topic Author is listed in the box below. For reasons of competitive fairness, direct communication between proposers and topic authors is not allowed after February 28, 2001, when DoD begins accepting proposals under this solicitation. TPOC: Owen Ritter Phone: 301-227-1647 Fax: 301-227-3106 Email: ritterok@nswccd.navy.mil 2nd TPOC: LCDR Frank Novak Phone: 703-696-8179 Fax: 703-696-2558 Email: novakf@onr.navy.mil After February 28, 2001 proposers may still submit written questions about solicitation topics through the SBIR/STTR Interactive Topic Information System (SITIS). If you have general questions about DoD SBIR program, please contact the DoD SBIR Help Desk at (800) 382-4634 or email to SBIRHELP@teltech.com. NOTE: The Solicitations listed on this site are copies from the various SBIR agency solicitations and are not necessarily the latest and most up-to-date. For this reason, you should use the agency link listed below which will take you directly to the appropriate agency server where you can read the official version of this solicitation and download the appropriate forms and rules. The official link for this solicitation is: http://www.acq.osd.mil/sadbu/sbir/sttr01/dod_sttr01.htm. DoD will begin accepting proposals on March 1, 2001. The solicitation closing date is April 11, 2001.