Object Management Group First Needham Place 250 First Avenue, Suite 201 Needham, MA 02494 USA info@omg.org http://www.omg.org Tel: +1-781-444 0404 Fax: +1-781-444-0320 Space Domain Task Force CORBA-based Space Communications Request For Information RFI #2 Submissions Due: 22 October 2001 OMG Document space/2001-07-11 11 July 2001 1 Introduction This Request for Information (RFI) solicits information about requirements, technologies, and software products in the area of software interface elements for Space based CORBA objects. The Object Management Group (OMG) and, specifically, the Space Domain Task Force (DTF), with the support of the Architecture Board (AB) will use this information to begin the technology adoption process, which will define an OMG-standardized architecture, and set of interfaces, which will address Space based CORBA objects. For additional information about OMG and CORBA, see reference material at the end of this document. The OMG encourages users, consultants, software development methodologists, and developers of software to become involved with this process by responding to this RFI. OMG non-members and members may submit responses. The Space Domain Task Force expects to use responses to this RFI to define one or more RFPs leading to OMG-adopted specifications in the area of Space based CORBA communications. The OMG Technology Adoption Process is run according to the procedures laid down in the OMG Policies and Procedures.(http://www.omg.org/docs/pp/98- 08-01.doc ) 2 Context and Scope Traditionally communications between satellites and ground stations in the Space Domain have used datagram-like protocols such as CCSDS Command and Telemetry. Recently there has been experimental and research efforts exploring the use of Internet (and Internet- like) protocols to replace or augment the current communications system. The motivations behind this include potential cost savings, easier or increased interoperability with ground based Space domain networks, and leveraging Internet applications and technologies into Space more easily. CORBA is an example of an Internet technology that has been shown to be useful in the Space domain as part of the applications that run in the ground segment, such as the control center. In this instance, CORBA is used in various ways to build distributed control center application functionality, provide remote interfaces accessible over the network, or even to distribute data to other "back-end" applications. But with the advent of Internet or Internet-like protocols into Space, in essence connecting a satellite to the ground network as a network node, some (or all) of the functionality just described can migrate its way up the space-link so that a CORBA application on the ground, could in theory be partitioned to run all or partially on the Spacecraft itself. This blurring of the line of demarcation between traditional Space and ground segment applications represents one of the key motivations behind the desire for "Internet" in Space technologies such as CORBA. Additionally, as a network application, CORBA could be used in more complex scenarios besides just a single spacecraft to the ground segment. Networks of Spacecraft, as well as, networks of ground stations, all intermixed in various ways, can be considered as open to distributed space based applications. These applications could, in theory, leverage ground- based resources seamlessly with space-based assets – creating a fusion of technology not available in the Space domain before. It is with this powerful motivation in hand that the Space domain task forces seeks to begin the efforts needed to standardize CORBA for the Space domain, and in particular (for this RFI) the space to ground link and related areas. Work may have to be done within the ORB and the standard set of CORBA services to support this concept to its fullest. Additionally, higher-level domain specific services may also be defined in this context that are not currently part of the CORBA services set. These services have not been identified yet. Further, the use of CORBA in space applications is viewed as being more appropriate for monitoring and control, and other more efficient mechanisms will be used for bulk data transfer. For example, it is unlikely that a large image would be transmitted using CORBA – but would be managed by a CORBA interface instead. It may be that a higher level of abstraction will decrease the bandwidth necessary to carry out ground to space communication. The following diagram more fully illustrates the basic concept of using CORBA across the space-ground link. Diagram 1: CORBA Ground to Space Concept The illustration shows two satellites connected to a single ground station and a back end "user" at the control center. Note that this diagram is for illustrative purposes and not meant to be imply a specific design or solution. The CORBA arrow represents the path of an "end to end" CORBA communications between a ground based application and space based objects. The communication could be in either direction however, and space applications could call ground-based objects as well. This example is one of many possibilities, which could include multiple ground stations, control centers, distant end users, and groups of satellites in various permutations. As the illustration indicates, CORBA requires a transport protocol to work properly. Out of the box CORBA supports TCP as the transport protocol (IIOP). Because Space communication may use alternate protocols besides TCP – some of which may not be transport protocols at all, the CORBA Space community must address supporting these protocols in some fashion. Current alternatives include SCPS ('skips'), a variant of TCP/IP for Space standardized by the CCSDS standards group, the CCSDS command and telemetry standards, which do not have transport protocol like properties, and other non-TCP protocols such as UDP. Supporting any of these approaches in CORBA communications will require additions to the CORBA standards as currently defined, including TCP/IP. In addition to the basic issue of the underlying communication medium for CORBA ground to space (or space to space), there are numerous other issues that have been identified to fully support CORBA over the ground-space link. Location Services (e.g.: Naming, Trader)/Remote Object Look-Up ? Remote space objects may register with the ground based ORBs ? Remote object lookup is expensive for the space to ground link and needs to be minimized Security ? Applicability of CORBA security standards to the Space/Ground link ? Compatibility between Secure Sockets Layers and SCPS-SP (or other protocol specific security protocols) Connectivity Issues ? Use of CORBA routers to store & forward commands either on the Spacecraft, or at various points in the ground segments. ? Quality of Service support for transient connectivity of satellites Footprint and CPU Issues for Flight Software ? Flight CPUs are one to two orders of magnitude slower than current desktop systems and will continue to be into the future ? Memory is at a premium on-board While this list is not exhaustive it does help begin the discussion of CORBA over the space- link. 3 Objectives of the RFI This RFI seeks information to help the Space Domain Task Force proceed in establishing and standardizing Space based CORBA, and in particular CORBA over the space-ground link. The OMG standardizes interfaces and the underlying technology to support it. The interfaces can be active at the time of analysis and/or design of the behavior of the software, at compile time (including compilation with IDL compiler) and/or at run (execution) time. A goal of the Space Domain Task Force is to standardize interfaces for Space based CORBA objects to facilitate the operation of satellites, ground to space, and space-to-space. Satellite operations include all current satellites activities such as commanding, distributing operations telemetry, and distributing science data. The OMG would like responders to provide information about available technology to facilitate framing of Requests for Proposal (RFPs), and to provide a set of topics to discuss. Examples might include domain specific infrastructure, platform extensions, IDL extensions, and/or Object Request Broker (ORB) services. 4 Information Being Requested This RFI is seeking information in the categories described below. Respondents are asked to address areas in which they have expertise and/or interest. Please consider the objectives of this RFI when responding so time is spent on issues that will be helpful to reviewers. Respondents may consider areas not explicitly asked for if they feel the information provides useful guidance. In addition, OMG is requesting descriptions of trends of which the Space Domain Task Force should be aware as OMG prepares for the technology adoption process. 4.1 Space Based Transport Protocols The OMG requests information on availability, maturity, and importance of any plans, current or in the future, to support some variant of TCP/IP in Space, either as the primary communication medium or as an advanced service on-board. In addition the respondents may wish to consider the overall architecture of a general space to ground network that includes multiple ends users, ground stations, control centers, satellites (heterogeneous or homogeneous), and communication paths. Also, respondents may wish to consider the use of these protocols over transient links, and how this might relate to work already done by other groups in the wireless domain. Finally, respondents knowledgeable about the inner-workings of CORBA may wish to address issues related to sending GIOP messages over transient links, and how that may relate to on-going activities for wireless CORBA support. Additional areas may be considered as well, and include, but are not limited to, the following items: ? Bandwidth Implications of CORBA over the space-ground link ? CORBA and Interplanetary Internet ? CORBA over SCPS, CCSDS, UDP, CFDP, PPP or any other protocols not mentioned ? Multi-hop commanding, multiple communications paths, and other connectivity issues associated with the transient nature of satellites contact to multiple end-points ? CORBA routers and bridges 4.2 Existing Implementations, Research Programs, Test Beds, Etc… The OMG requests information on availability, maturity, and importance of any existing models, products, methodologies, etc., which support the Space based CORBA concept. Other technologies might be applicable such as real-time JAVA, JAVA RMI, SOAP, Microsoft DCOM, XML and UML, to name a few. 4.3 Standards or Proposed Standards Areas The OMG requests information on relevant standards or proposed standards areas, both de facto and de jure. Where multiple standards exist, respondents are asked to compare significant differences among them. It is also important to identify problems with current standards that prevent their acceptance or cause problems in their implementation. Areas applicable to space include, but are not limited to, wireless, real-time, embedded, security. 4.4 User Requirements The OMG requests information on user requirements for mission applications that would or have benefited from CORBA in the Space domain. This could include ground-based applications, and how some or all of their functionality could be moved to the spacecraft. Or this could be conceptual space-based applications that would benefit from a distributed object technology like CORBA. 4.5 Location Services The OMG requests information on location services for Space based objects over a transient, mobile link with limited, possibly asymmetric bandwidth. Responders may wish to explore the difference between dynamic and static objects for the location service. 4.6 Security The OMG requests information on the aspects of security as they relate to the space ground link. This can include the applicability CORBA security standards already in place, or planned standards. In addition, security interoperability between space based security protocols and ground-based protocols would be applicable. Larger systemic or institutional policies, or security requirements for the space ground-link can be addressed as well. 4.7 Distributed Space Based Applications The OMG requests information in the area of space based applications, either current, conceived or planned that would benefit from a distributed object framework such as CORBA. Possible space based applications include, but are not limited to satellite constellations, either homogeneous or heterogeneous and dynamic or statically defined, advanced inter-satellite information sharing for science processing, sensor web and other related technologies. 4.8 Commercial Applicability The OMG requests information on the commercial applicability of CORBA standards over the ground-space link. 4.9 On-board Issues The OMG requests information in the area of on-board computer resource either current or planned for space missions. This would include CPU types and speed, memory footprint, number of CPUs. If it is applicable, advanced hardware processing elements such as FPGAs could be included. Also the respondents may wish to consider the OMG embedded specification for comparing with space based computing assets. 4.10 Minimum Services The OMG requests information on the minimum set of services, and/or minimum profiles within the services, required to support CORBA over the space/ground link. 4.11 Maturity The OMG requests information on the maturity of CORBA/OMG technologies space based applications, either perceived or real, and how it will be deployed. 4.12 Manned Flight/Space Station The OMG requests information in the space based CORBA or other OMG technologies to manned space flight. 4.13 Space Management Service The OMG requests information on the services that are needed for Space Management. This includes but is not limited to: ? Software uploads and upgrades ? Garbage collection ? Mobility Management ? Authentication 4.14 Quality of Service Adaptation The OMG requests information on the area QoS adaption on the RF link and how this should be handled at the ORB level for Space based applications. Technologies related to this include but are not limited to Software Radio, and dynamic pluggable protocols. 4.15 Other Information OMG requests that respondents furnish any other information they think may be relevant to this topic. 5 Who May Respond to this RFI Any person or company may respond to this RFI, including both OMG members and non- members. OMG especially encourages civil and military aviation organizations, users, consultants, software development methodologists, and developers of software to respond to this RFI. However, only Contributing Members of the OMG will be eligible to respond to any follow-on RFPs issued as a result of this RFI. Any company may join OMG at the contributing member level and respond; see the OMG website (http://www.omg.org) for membership information. 6 Instructions for Responding to this RFI Reponses are available to the public. Organizations responding to this RFI shall designate a single contact within that organization for receipt of all subsequent information regarding this RFI. The name of this contact will be made available to all OMG members. Responses to this RFI must be received at OMG no later than 22 October 2001 to meet the OMG Policies and Procedures requirement that all responses to RFIs and RFPs be available at least three weeks prior to the meeting where the responses will be considered. (See below for more details on receipt dates and addresses). This Documentation submitted in response to this RFI will be available to all OMG members. This reduces the risk that Technical Committee and Task Force members will arrive at the meetings to review proposals without having seen them and provides time for the OMG to send papers to its members. NOTE: According to the Policies and Procedures of the OMG Technical Committee, proprietary and confidential material may not be included in any response to the OMG. Responses become public documents of the OMG. If copyrighted, a statement waiving that copyright for use by the OMG is required and a limited waiver of copyright that allows OMG members to make up to fifty copies of the document for review purposes only is required. Format of RFI Responses The RFI response can consist of pre-existing product documentation, but should preferably be organized and presented in accordance with this RFI. The following outline is offered to assist in the development of your response. You should include: ? A cover letter -- the cover letter should include a brief summary of your response such as indicating which areas you are responding to and indicate if supporting documentation is included in your response. ? Your response to any or all of the areas of information requested by this RFI. ? If required, a glossary which maps terminology used in your response to OMG standard terminology. (See the Appendices to the OMA Guide and the CORBA Specification for OMG's standard terminology.) Although the OMG does not limit the size of responses, you are asked to consider that the OMG will rely upon volunteer resources with limited time availability to review these responses. In order to assure that your response receives the attention it deserves, you are asked to consider limiting the size of your response (not counting any supporting documentation) to approximately 25 pages. If you consider supporting documentation to be necessary, please indicate which portions of the supporting documentation are relevant to this RFI. How to Submit OMG requests that submitted material be attached to an email cover letter and sent to our process manager at juergen@omg.org. The preferred formats are ASCII text and Postscript. PDF, MS WORD RFT and Frame MIF may additionally be used. In addition, one paper copy is required (as a backup). The Space Domain Task Force plans to review submissions at the November 2001 meeting in and/or at the January 2002 meeting. Responses to this RFI (and other communication regarding this RFI) should be addressed to: OMG: Space Domain Task Force First Needham Place 250 First Avenue, Suite 201 Needham, MA 02494 USA Tel: +1-781-444 0404 Fax: +1-781-444-0320 Email: juergen@omg.org Email responses to this RFI must be received at OMG no later than 5:00 PM US Eastern Time (22:00 GMT) 22 October 2001 and the confirming paper copy must arrive at OMG shortly thereafter. The outside of packages/envelopes containing submissions or any other communication regarding this RFI should be clearly marked "Space Domain Task Force RFI Response". Reimbursements The OMG will not reimburse submitters for any costs in conjunction with their responses to this RFI. 7 Response Review Process and Schedule Process RFIs such as this one are issued with the intent to survey the industry to obtain information that provides guidance that will be used in the preparation of RFPs. The OMG membership, specifically the Space Domain Task Force will review responses to this RFI. Based on those responses, the Space DTF will consider revision / extension of its domain architecture, a corresponding roadmap, and one or more RFPs. In accordance with the OMG technology adoption process, each issued RFP will ultimately result in the specification of a portion of the architecture. See below for a brief description of the OMG technology adoption process and consult the OMA Guide for a complete description of the OMG's requirements, policies, and procedures for technology submissions. Clarification of Responses To fully comprehend the information contained within a response to this RFI, the reviewing group may seek further clarification of that response. This clarification may be requested in the form of brief verbal communication by telephone; written communication; electronic communication; or a presentation of the response to a meeting of Space Domain Task Force. Schedule The schedule for responding to this RFI is as follows. Please note that early responses are encouraged. TF recommends issuing the RFI July 12, 2001 RFI issued July 13, 2001 RFI responses due October 22, 2001 The tentative schedule for the RFI evaluation process is: Review of RFI responses November 12, 2001 NOTE: This schedule is subject to change based on the number of RFI responses received and the information acquired from the responses. 8 References Richard Soley (ed.), Object Management Architecture Guide (OMA Guide), Third Edition, Wiley. June 1995. Common Object Request Broker: Architecture and Specification (CORBA), Revision 2.2, http://www.omg.org/corba/corbaiiop.htm CORBAservices: Common Object Services Specification, Revised Edition UML documents (ad/97-08-04 and ad/98-08-05) (http://www.omg.org/docs/ad/97-08-04.doc and http://www.omg.org/docs/ad/98-08-05.doc ) Telecom Wireless Mobility RFI: telecom/2001-07-01 Space Domain Task Force homepage – http://www.omg.org/space SCPS References – http://www.scps.org CCSDS References – http://www.ccsds.org More information about the Object Management Group can be found at their website: http://www.omg.org Page: 1 Space Domain Task Force Request For Information space/2001-07-11 Page 12 Page 1