Meeting Minutes OMG Transportation DTF Montreal, Quebec June 24-25, 1997 Attendees: Mr. Roger Courtois courtois@cn.ca Canadian National Railways Mr. Junichi Toyouchi toyouchi@sdl.hitachi.co.jp Hitachi, Ltd. Mr. Antony Reynolds antony.reynolds@swi.galileo.com Galileo Ms. Therese Smith tmsmith@ll.mit.edu MIT/Lincoln Laboratory Mr. David P. Whitman dave@dsc.camber.com Camber Corporation Mr. Jim Farrell ?????@weseley.com Weseley Software Corp. Mr. JeanPierre Belanger jpbelanger@originalsim.com OriginalSim Inc. Mr. Tony Ng tony.ng@lmco.com Lockheed Martin Mr. Patrick Place prp@sei.cmu.edu Carnegie Mellon University Mr. Craig Kelly craig@omg.org Object Management Group Mr. Thomas Barker thomas.barker@lmco.com Lockheed Martin Mr. John F. Lewis jflewis@switch.com Union Switch & Signal Mr. Paul A. McGee Union Pacific RR Mr. Al Marshall Canadian National Railways Mr. Felix Rausch Meeting called to order at 9:00 AM by chair John Lewis. He stated that since we had gotten approval from DTC in Stresa, this would be our first meeting as a Task Force, which means we can issue RFIs and RFPs, evaluate and vote on submitted technology John said the first order of business was to identify a chair for the Rail group. A suggestion was made by Therese that Roger Courtois chair the group. Some discussion ensued. The issue was then tabled until tomorrow's meeting of the Rail Working Group. Next item of business was recruiting. We need additional members, recruits we had more than 12 at last meeting, when in Europe, which was very encouraging, and we did have commitments for today, but many have not yet appeared. Personal networking has been requested of every member in the group to address this issue. Everyone's action item. Some methods suggested included talks/flyers at trade shows and orgs, like AAR, other conventions, collocate with other standards group, e.g. IEEE. The question was asked, why are we not holding interest of other railroaders? They have come, but haven't returned. a. someone else is really doing this, they could come and watch, or b. thought before that it would be faster and easier that it appears when they do come c. priorities It is hard to drum up interest in producing RFPs. It is felt that we need RFPs out there to get the interest going. Bootstrapping, positive feedback, vicious cycle sort of thing. RR industry hasn't gone to standards as a way of doing business. Rather, someone takes a leap, others copy. Mr. Toyouchi of Hitachi said he hopes to recruit more members from Japan. Further discussion on rail specific things was deferred to tomorrow's meeting of that group. Common Working Group Item 1: Progress on Lexicon, intermodal: Roger Courtois contributed some material, and Therese has taken an action item to add them to the lexicon Item 2: Issuance of an RFP to solve interoperability problems Topic put forth at prior meeting was intermodal service request/confirmation scenario type of interfaces in order to allow a consumer to address a reservation facility, either web, client based. Client can request a service, which may or may not involve intermodal routing, system replies with intelligent answer as to whether the requisite carriers involved have the capacity to fulfill and confirm that request. This was felt to be a good 1st RFP topic, as Galileo and SABRE members are in this business, And it also benefits all of the the modal members, as each have intercarrier or intermodal carrier Reservations requirements. Sounds reasonable, at first, however, after thinking about the practical requisites for success of RFP process, it begins to look hard, maybe like biting off too much in an area that is as yet poorly defined nad has no present solutions? Talked next about what would be necessary for RFP to succeed, and how we could take a pragmatic, practical view about what would be good to work on. Considerations: user drivers or benefits vendor drivers and benefits Who would use, who would submit against. We must know this before hand. John asked the group members how they viewed the value and viability of this RFP topic from their perspective: John: What benefits for Roger Courtois/CN? Roger: The driver is the ability to be flexible, make schedule improvements quickly CN need for intermodal, other railroads, truckers pick up shipments, traffic Arriving. Would need to know how does it dovetail with ongoing RR issue called ASM, high way to rail, would it be beneficial to use . John: What might Wesley get out of this? Jim: Need interface to external systems, customization for clients, need for a standard John: Is this topic a key issue for him? Jim: Yes. John: How about Hitachi? Junichi: We develop large scale metropolitan area systems develop step by step, 200 stations connected cannot address all at once, large scale, so convert one by one step by step development, maintenance of SW for distribution system John: What about reservation systems? Junichi: Shingasu, super express, Japanese national RR, and do market an intermodal, one program for research in Japan, domestic (country is an island). Shingasu competes with aircraft- Tokyo-??? route. Requirement to show the connection, nice to show both. John: What about an intermodal situation requiring a train, then a truck, then a train. Junichi: Such a requirement is submitted, sent to other agencies, make one pass, such work is not computer system, rather skilled worker. (Opportunity for automation?) John: Would Wesley submit to such an RFP? Jim: Yes. John: How does Galileo see this RFP topic? Antony: This intermodal scenario is really the only one we are interested in. rail struggled- rail has too little margin to work with Galileo, strictly for human passengers, maybe with standardization, could drive down cost We may submit interfaces in response to this. John: Everyone should be aware that a domain contributing membership is needed to respond to RFPs. Also, before you submit, must submit LOI, and guarantee that if your submission is adopted, you will make a commercial implementation of the software available publicly within 12 months of adoption. Antony: You know, we don't market a software application, but an interface API to our application. Based on the Galileo model, the largest Internet booking is Apollo, just a few 100,000. Agency wrote their own software based on our API. PC travel used it to build a web site, but they did it themselves. If we specifiy an Interface at that level, then subscribers to Galileo can exercise the interface. Executable component is different from API. People seem to have differing ideas about what the DTC is doing. Some think it is to buy business objects you can "womp" onto your system. Our system, at 2000 messages per second, is not the sort of component you would want to drop on somebody. We want to run it and offer standard interface. Configuration, system administrators. different business models, components vs. service. Galileo wants to produce APIs, so as to allow others to be able to access Galileo in a standard way. Development of a common interface, vs. components. Links to literally 100s of airlines - this interface is a part of their service. We'll talk about it later. They could offer a front end that allowed someone to use Galileo's service. Standard components with standard interfaces. Client could communicate Component encapsulate, not an executable that would drop it, we run it at Galileo, customer can interface to it. if the API is common, people could pick Galileo or SABRE readily, on the basis of the quality of information (and connectivity). RR comment: what about finer granularity products? John: Are we taking too big a bite here? Should we ask for something more modest? What do the CRS folks in the room think? Antony: basic reservation process is very limited, e.g. with an airline exchange 3 reserve, sell, cancel, schedule change message, charge extra for asking about capacity. Sometimes they sell without knowing whether there is a seat, sell will fail if there are not enough seats. John: This is a subset of intermodal, Jim would talk about a different subset. Would either work on a generic enough subset that would cover both, together? John: We need a list of all possible transactions that you would need in intermodal. If we worked together would we want to enumerate the kind of services that you would need to conduct intermodal. E.g., cover both passenger and freight? Preliminary work in this area is to figure out what scope of an RFP should be. Antony: Yes, we have to. Galileo concerns itself with rental car, too. John: This RFP will require us (no, the responders) to define large numbers of domain objects, waypoint, route, etc. It covers a lot of domain foundation objects. Pause for thought. There are an awful lot of differences between CN's, and Galileo's use of terminology, for example. John: Another activity for this group is the development or acquisition of a reference model, complete one for transport industry, which should sit on top of a more general service industry model, and which is itself specialized into air transport, rail transport, etc., The common transport model would capture the similarities between the modes. For example, the concept of route, has commonality across all modes of transportation, for RR, etc. We must identify all or at least most, of the interfaces in this model, so that we can know which pieces we want to attack, how they are coupled, what the priorites are, etc. We are not even close to having such a thing, it is a large body of work. OMG has not defined what it should look like, and there is no generic service buisness model for us to stand on and pattern ourselves after. So we can't work purely top down, form a reference model. We will work on getting one, but meanwhile, each WG, air etc., must try and identify some safe lowhanging fruit to pick, something with little potential for being made obsolescent by reference model. One class of such interfaces is the one comprising CORBA 'bags' around legacy standard interfaces. Fast, easy, relatively safe architecturally. Equipment register wrapper safe architecturally, we might want to try and identify something like that in our arena, high probability of success. Antony: Galileo has a completely different model, not always safe to bag up what you've got, network traffic, WAN links all the time, CORBA seems to assume high speed LAN, close together, many CORBAservices don't work well over WAN. Client application programmer to actually understand what's going on. Want what's certain is stable. Don't want to get into situation where there are no responders, or lots of conflict or confusion. John: What about RFP for reference model. Would anyone reply? A commerical trasnportation model got submitted to our RFI that follows the Zachman framework. An intermodally developed (Air Mobility command, Art of Transcom) gave us some selected objects from their model, some definitions, specific examples of objects, and commercial american president lines , american express and CSX. vehicle, conveyance John does not have much problem with that model. See that individual vendors had to add attributes to model for their conveyances. Roger: I would if help if there were a ... process? John: Really, I think these reference models will be a general problem in domains, since the production or requesting of them doesn't fall within the present procedural boundaries. We can't do development work of technology, not even specifications. Others: What about if members are willing to pay for it? What about OMG changing process for us? John: I am trying with Andrew Watson, Dave Curtis, Richard Soley to get this changed. John: I think this beats the RFP/reference model topics to death. For the RFP in question, we lack participation. What about Wesley and Galileo any near term intention to become members of OMG, and which would be interested in developing RFP? Jim: Wesley, that's why we're here now. But we will not develop the RFP. John: Union switch does not have much interest in this, however, I would be happy to help as I can. Anthony: It all comes down to priorities, people are just being started. Weseley, is interested in this, but the value for Galileo is not the interface, but the service. Senior managers are not all sold. Internet thing has helped.Apollo sells more on Internet -- just happened to be first to have the agents that fit with Internet. Trivial amount of business that comes through that way. 70%, could have done cheaper by travel agent. Jim: Wesley is here because of this RFP, sent to find out what OMG is about, A good opportunity for the company to pave some of the paths. Picking low hanging fruit is good path to take. John: If nobody is willing to take an action item on this RFP topic, then we surely don't get anywhere. If there's no one wants to work on this RFP, it's a bad idea. As far a I am concerned, we will discuss this topic seriously only once more. People say they are interested, but are unwilling to work on it. If no one volunteers, it will be tabled. Are there other ideas for RFPs that people are willing to work on. I think in order to solve this resource problem it is imperative that we closely align our work here at OMG with the work we are doing anyway back home. That way the minimal amount of extra work is necessary, responses to the RFP are guaranteed, and it is sure that members will receive the most immediate value for their efforts. Anthony: Galileo has an old project- air, car, and hotel, how do you sell at once? How do you fare? Are there multiple people in the user community that want it, same for vendor community. This is an idea for an interface, if it meets those criteria, John: This is the same idea. Intermodal reservations. Were there problem statements that were collated? No. One RFI respondent, Fedex, spoke about a rather broadly defined interest in defining the kinds of objects to do what we're doing now (intermodal res.), but they have not bothered to attend a meeting. CN listed in their RFI response the order in which they'd like to see problems attacked. Speaking for Union Switch and Signal (we made some statements about our priorities in our response, also), we are particularly interested in interfaces internal to the RR applications systems. Strategic planners, tactical planners, (to a CTC system) alarm systems, control systems, etc. Union Pacific still promising to respond to the RFI. John's systems require RT interoperability with other rail control members (he needs broadcast messaging, e.g., as he discussed this morning) Antony: Suppose we succeeded to get a product idea for an RFP, is the platform suitable? If the interfaces required a lot of security, we couldn't do it now. Message based comm, can't do that right now. If wanted to access the Galileo Apollo system, could he do it? Don't know. John: There are numerous examples of large, mission critical systems built on this platform (at least in large part. Extensions are something that is often necessary, and probably will be for the foreseeable future.) wells fargo.com, is CORBA with their legacy code, Iridium satellite network project is ORBIX based. John adjourned Common Group meeting at noon. 1:30- Meeting of Air Working Group called to order by chair Therese Smith. Presentation from Tom Barker: worked on Gemini RT system now tracking on AWACS do have friendly transponder support enemy does not necessarily furnish flight plan going into open systems AirForce selected, due for deployment in 98 timeframe novel tracking approaches, Lockheed Martin patents, is commercially available, pieces of tracking sensor fusion client/server iopen, distributed, multiple platforms n dimensional assignment optimization theory object oriented fashion sensor fusion bistatic radar, local TV transmitters irradiate, and AWACs receives... various direction finders also imaging, as in ground image, can get info from that partition from time oriented to track oriented what in each input caused by each target multiple sensors, repartition into target related tracks compte intensive, so want multiple processors, are objects a track, a gating process? how to make object related gate: match sensor inputs against tracks is gate filter and score: Kalman, least squared or other smoothers, derive figure of merit how does track file get extended: use to generate new gates multiple hypothesis testing next scans support (or not) hypothesis extends to sensor fusion, other infor can come from other sensor MHT process number of hypothetical extensions process these with combine and prune hypotheses can be combined, branched off, false a not very good algorithms to look across entire hypothesis tree no formally defined algorithm in an easy way that was the status when tom started on this formal optimization techniques took MHT and added N-dimensional assignment is an NP complete problem but for tracking only needs to be solved to the noise level, (i.e. uncertainty from the radar) 3D is track histories, can be k dimensional he has a method that converges to a solution, is Lagrangian relaxation, unlike traveling salesman, only approximately know the location of the cities so he can go faster could be 2 scans, could be 20 scans, varies, gating extends the hypothesis tree, it extends solve for best use of data within tree extension , maximum the likelihood of the solution subset results, can prune off moves forward the hypotheses tells the best solution they have extesion to sensor fusion radar scan at different time as e-scan or iff(transponder0 hard even to break into scan, but can partition into sections can filter and score, solve the same, prune and same way two databases appear in overall loop, initiation of tracks, track extension (has Lagrangian) each has a database move this into an open system control program not immediately CORBA, but is wrapped sensor input into wrapper, data stabilization (orientation of the airborne sensor) -> OO database OQL support, the database is drawn close to tracker, other database is lower, labeled OO updates to display controller monitor can send inputs to adjust tracker CORBA connects operator interface, tracker ad fusion is one or more processors, database can distribute across, FT redundant mechanisms also present tracker modified to use OO database with OQL, create data structures, objects are reports, tracks , number of objects by database is larger than by ORB, 50-100,000 hypotheses at a time. #tracks is in excess of a thousand like to ba able to plug and play, things within tracker, like filering and scoring, track gating, his customer may want XYZ filtering approach, don't want to rebuild whole tracker infrastrucutre, hypothesis several techniques, applicable to different situatuions, can substitute can adjust run time environment, based upon load database by Lockheed Martin, ORB also, significant RT requirements make or buy study, requests to vendors, got no response 3 years ago, tom's programmers looked at corba, database as exciting specialty developers wanted to make as opposed to buy database can be packaged as shared memory local accesses by individual processes, C or C++, APIs to go into database get the same performance as they are used, also can be separate by CORBA backplane can ba acccessed read and write from over CORBA, extended smoothing after pruning conclusion ongoing, actvely extending from kinematic to incorporating info more attribute oriented, iff codes, crosssectional info, other go back and look at database, including flight plan (air tasking order) integrating tracker with imaging data, track ground targets with radar and infrared, consecutive images, platform motion for feature resolution within targets, open arch most effectively partition to make use of open system want to be able to make even more distributed stuff within RT special interest group, FT suggestions coming from his trackerwork, use features in the orb to provide FT and redundancy tracker has been driving force in ORB, real live examples, No suggestions about table of contents Felix Rausch presentation: users and RTCA committees architecture plan, constrained by funding levels 2.3 billion per year, first cut looks a billion over NAS Airspace System Information Architect National Aviation Safety Data, NASDC does not wish to rank airlines promote safety, also commerce NAS architecture group, is fairly large, TRW and MITRE support his group is missionaries at this point, dealing with a whole lot of engineers, controllers and pilots, understand iron, but this is now an information system, computers and databases talking to one another, need an information architecture, database schemas and overall architecture, now taking off this year, by the end of the year with the 3.0 architecture, include costing the information administration cost by illustration, putting together are systems engineers CNS comm nav, surv, ATM air traffic management LIS local information system possibly cost it out several data marts, data has to manipulated quickly multiimensional overlaps, reach real time, maybe three years, needs are ahead of what is available commerically now costing it this week concept of operation, everything will be run by NAS wide information system flight information object, chock to chock, gate to gate not just an extra add on cost it will in fact save you money now convinced it is not an extra cost, all included, tax each of the domains that are spending large amounts of money they will do inforatmion architecture, who knows which contractor many or one and save a lot of money that is background Felix volunteered to talk for a short time. presentation on flight information, based on concept of operations picture of NAS Information system logical, conceptual maybe they can contract all of it out wx, there are so many suppliers all consumers all look at the same picture when they or their computers talk to each other NAS ATC network, mainly voice maintenance, RMM, central control facility, NIMS facility, have to propagate the information realtime with DoD and international international flight plan filing running with voice RT link, less of that we're adopting ASTERIX, ICAO flight plans flight info object what do you do with unidentified one not much differetn from EATCHIP, the European proposal, weather maintenance all has to communicate with each other data warehousing OO designs NAS Information Marts all need to be able to exchange information complex system flight information object, top down, functional level data definition when you do an architecture, you should have some principles permits dynamic distributrion of data, function, and responsibility VFR and IFR, more flight plans being filed RTCA 169, collaborative descision making, dispatchers, schedulers, contractors, MITRE, let them get into the air, they'll take care of the rest once in the air, they have the option and tools, to dynamically look at the connection reservations, see the ripple effect, whereas if you ground hold, there will be a lot more flexibility free flight is misnomer that stuck collaborative decision making, combined with Felix's dynamic distribution of data, has the possibility of affecting the way Galileo does he see an IPT for infrastructure, how can he put something out in the field that works, biggest problems is having other people mess with my contract, reuse for so-and-so, now one program gets dependent, cut control, and do it some specific way, most cost effective if the grammar, syntax semantics are defined the information flowing, data centric, rather than platform, heterogeneous platforms may help with fault containment, actual object specs, and his people are looking at CTAS and ETMS quickly to 2000 elements borrow from DoD, other systems in how about other countries, DFS, hopeful to some of Eurocontrol contacts using this to gain respect, logical design, not to data elements, does go to big implementation blobs, comparing flight data object with EATCHIP FIO preprocessing, 4 dimensional profiles (trajectory synthesis) flight data object: modified by pilot, service provider, AOCs, maybe schedulers and dispatchers, maybe others human factors aspects advantage of common data structure and methods, allows a lot of flexibility, replace algorithms and pieces of the system more easily than in the past, don't need all for standards for things going into the field any standard is better than none. FLT2000 testbed in alaska and hawaii VP Gore, also Mr. Donohue, is in favor it is really a CNS project opportunity missed if in flight processing Internet concepts will come into play, push and pull of data best way is to have data centric, doesn't matter what processing techniques come along, don't change the semantics of what is going on. Infrastructure can change could have, for example, always an alternative trajectory, analogous to alternative airport support for other service providers, military, en route, oceanic, consider support of fee for service, overflights, demand capacity planning, makes ETMS database big topic replay the whole scenarios, scedulers, next steps: define funtional architecture data elements data sets got to executable model, emulate how the information flows inside demonstrations, interactions with people scenarios from conops people drive the system technology is an enabler Cemex using OO things, trucks are driving around city, so if someone calls, deliver within 5 to 10 minutes, permit coordination of architecture with customer Questions to Felix: John: asked, how to achieve the executable models described. Felix: can do one for $20,000, can build on, expand, commercially available tools ATC knowledge, target acquisition off the shelf tools, 3 vendors that can do it. John give card and Felix will send names, Therese: made the announcement about the Object World meeting, including the speakers, and asked for suggestions about future meeting activities. receiving none, Therese closed the meeting. Meeting of Rail Working Group, Wednesday, June 25. John called meeting to order at 9:00 Am. First topic of discussion was the UMLER/IRF RFP topics. John stated that the AAR was going to be a problem in this regard, as they 'own' these standards and files, and they have sent email saying they are not interested in participating at this time. General discussion ensued regarding the AAR and the IRFs. The general conclusion was reached that the AAR's attitude was going to make these impractical targets for a quick RFP. Paul McGee of UPRR stated that a Client Information Facility would be of interest to them and to other railroads, as well. We talked about what such a facility might include. Paul said such a requirements effort was underway at UP. John reminded him of the AAR Net-REDI program that might be used for this purpose, as well. Paul thinks this would be a good RFP topic for him to work on. US&S is not particularly interested in this one right now as it does not coincide with development/marketing plans. Paul will proceed to explore. Roger Courtois of CN is interested in the reference model, but doesn't see how we can get one, since its shape is not defined, and we don't have near enough volunteers to do it. John says that RM-ODP is one model standard we can rely on as it is endorsed already by OMG, but it does not really specify all that much detail, or ant process or methods. Roger and John agree to have a meeting with Eric Aranow to determine if he is able to help in these efforts and definitions, as he seems to have some experience in modeling businesses in a way that translates into systems models.