# RailML for use with software controlled railways



## Brandon (Jul 6, 2011)

As to avoid hijacking another thread this thread is to discuss the use of RailML (http://railml.org) as a way to define a garden railroad layout for software to run.
As posted from VictorSpear on his "Next Gen" thread


I'll take the liberty of posting technically again what is meant by this. Take a good look at the sample schema that defines the characteristics of trainid rse002 for real world loco BR186 in the 'samples' from RailML. The schema has shared publicly the Bombardier transportation key elements that my interface needs to determine what I'm dealing with: Electric, Braking effort steps, ..Speed steps. Simply replace this with the type of motive power for the exact model you are offering on your layout and whatever attributes are* known to you*. For example, the sound triggers now should trigger to the exact Braking effort in the BrakeEffort graduating tags in RS_tablesample.xml - now they are synchronized to the real world as opposed to a pre-recorded screech that suddenly appears and disappears because someone recorded something somewhere. If I am modeling the braking characteristic (with sound) of the Bombardier BR 186, I'm using the same data as the prototype that's in the no-argument public domain. QED.

RailML appears to be very thorough and covers most of what I imagine a garden railroad would need to operate trains in a more realistic way by specifying speed tables and braking tables. One question I do have is whether you intend to extend the RailML schema to handle commands to/from the locomotives as well as sensor data, or will this be through another protocol? 


Also what are the plans for handling the modeling portion of layouts? Since the real trains operate at different voltages than model as well as model trains running on battery experience performance (aka voltage drop) as fuel runs low which if it can't be monitored or offset would cause non-realistic speed table and brake table stats. Where is this variance managed?


Also do you happen to have any sample RailML of a layout? That would potentially answer a lot of questions I haven't brought up about track/layout in RailML and I'd also be curious of you could share any locomotive or other sample files you've been working with. For my automated railroad I can see using RailML (though it's likely overkill for what I'm doing) but if I can create something that can work together with what you and your students are doing it could open more doors for everyone.

Brandon


----------



## Greg Elmassian (Jan 3, 2008)

Reading what railml is, it's not the control system, but a method to CONNECT different actual prototype control systems (actually more generally any IT application that is used with railroads). 

The fact that it is trying to be the "glue" between systems means that it is supplying a "data structure" to communicate any type of data. 

The good news is that basically any information should be able to be represented, now, or with extensions later. 

The bad news is typical of any "least common denominator" software, it get's big and inefficient if used for a more specific, constrained purpose, like our model railroads. 

Since this is only data, it should not impact performance of a control system, but it must be viewed as a communication medium, not a control system. 

From the web site: 

"The railML.org Initiative was founded in early 2001 against the background of the chronic difficulty of connecting different railway IT applications. Its main objective is to enable heterogeneous railway applications to communicate with each other." 

So, while it may be a nice way to STORE the information about things, it's definitely only the "data representation" part of what "a garden railroad would need to operate trains in a more realistic way". 

But, you definitely could use it as your "data warehouse"... 

Greg


----------



## Brandon (Jul 6, 2011)

Pretty much. That's why it could potentially serve as an option for a good base for those of us who want to develop software that operates a railway to follow. Imagine having your layout specified in RailML and locomotives and other information RailM. You could connect up a tablet to the 'network' using software A on the tablet, download the RailML for where you're at and operate the train(s) you want. You could also have a system running software B that also knows the RailML that monitors and controls the signals around the layout (and other accessories). You could also then have Software C that knows the RailML and maintains the remaining trains and the autonomous software to do that. 

VictorSpear is doing Software A&B while I'm doing Software C in this case. RailML is simply a way that someone could setup a RailML about their layout once and any piece of software that supports RailML could work from that base. 

RailML is likely overkill for what I'd need, but if people want to adopt it as a base (as it's been proven in the real world so it should work for modeling with fewer changes (and time needed) than starting from scratch) I'd be willing to consider using it so people don't spend time customizing flat files or other proprietary data sheets to make the layout work. I've already been thinking of how I could write a calibration package that detects RFID tags and distance between them (and detect where switches are) as well as grade, bends, and other things so if I'm doing that I could actually write and develop something that could generate RailML for people. Of course people would edit what was made if they wanted to add stuff that a train couldn't detect (signals and other stuff that a sensor car couldn't detect). 


Then if someone decides they want to stop using one piece of software they haven't wasted time setting stuff up. Also it would allow you to run any software you wanted that particular day. If you were to change the layout you only update one RailML and all the different pieces of software would read that new file.


----------



## Greg Elmassian (Jan 3, 2008)

Well, the database part is kind of "yawn".... from all the softwares out there in the real world, it's clearly a problem to communicate information between them. 

But it's overkill in size and complexity of the data structure, but trivial in programming effort... it's more "busy" work to come up with a data base to accomodate all the software packages out there. 

The real work is the control system and the networking between the components... do you want trains to be aware of each other? What will they do? Will the communication be a hub and spoke, or a self healing, self discovering dynamic mesh? 

There's some tricky stuff. 

But standards are good... if you put all your info in the RailML format, and someone makes a control system that reads it, cool... you can both work independently. 

I maintain though, that the very difficult part still remains the networking and the control and feedback systems. Making each locomotive an independent wireless bidirectional communications unit, and making it cost effective is a tall order... 

When you say people can run any software they want, that's a little tongue in cheek, they can run any software that is already capable of reading the RailML database, which, at the moment, is none. It will take some development to use that as a schema. The best idea would be to make an extension to JMRI since it's open source, and already deals with a database of sorts, albeit for the locomotives. 

I'd build on existing control systems, but that still means additional cost in every loco, over something like DCC or AirWire, which is already expensive enough that few people can afford a fleet of locos. 

I've also ignored any transponding of information of other cars. 

I personally like the rfid idea, relatively inexpensive per car, and the readers are getting cheaper. This is something you could do yourself with a minimum of programming effort, using something like jmri as a base. 

I have a better idea for detection of trains, cheaper than rfid, but takes more development, needs an RF engineer, so no use discussing it here. 

Regards, Greg


----------



## VictorSpear (Oct 19, 2011)

_"whether you intend to extend the RailML schema to handle commands to/from the locomotives as well as sensor data, or will this be through another protocol?" _ The RailML schema is fairly extensive and has been well thought through over the years - if you use something like Altova Studio and browse the DTD at pg P112 for example you will see the attributes for tunnels, bridges, level-crossings ....geoMappings. So we use the schema pretty much the same...to import the attributes of - for example - trainline RVZH (Uster to Walliselen to Zurich). Locally this is replaced in the track model garden layout with source updates to be anything we choose --- currently 'Hoboken to Jersey City PATH' with the Trans Hudson schedules from the Port Authority of NY/NJ downloaded. This requires only a simple monthly update from the web and an intra-day update from the weather channel for snow/rain conditions.


Are you referring to street lighting and landscaping layout models ? 


I'll put up some pix or clips of the Model 100A intelli-caboose assembly with simple back-and-forth trolley functions by one of my students later today. 


Cheers
Victor


----------



## Brandon (Jul 6, 2011)

VictorSpear: Any comments to my questions in post #1?


----------



## VictorSpear (Oct 19, 2011)

Sorry was shuttling between classes..Hey..good questions though. I think question 1 was answered in my earlier reply ?...Question 2 .. As mentioned earlier we use OpenTrack which supports RailML for TimeTable, Infrastructure and RollingStock schemas. For the sub-question on battery (fuel), it is always threshold monitored and trigger-alert is set to warn the yardmaster and ops to return the loco to the charging yard usually. I say usually, because other lazy stuff also happens. If an intelli-track and/or charging yard approach is used, the battery is always auto-charging below threshold levels so batteries* never have to be touched* or *swapped *for longer months of time. Are you suggesting that you could/would have the battery drain to standstill condition always ? I'm not following or grasping the question I guess.


Question 3: Although we use OpenTrack for simulations with various topologies as I mentioned in your other post on RasPi, for your purpose you can set the topology with the much simpler DTD in RailML itself. For example see the TrackTopology tag (TrackBegin, TrackEnd). Both Gradient Changes and Radii Changes are supported. For sample data, first look at the supplied xsd where all the units are declared. You may now remember the tee_id for location tracking from an earlier post where* each tie* is mapped ? There was the RailML mapping reason. Then look at TT_ICN file and under TrackTopology you will easily find the simplistic tag: TrackBegin, pos, id, TrackEnd... (remember to declare whether you are using Euro or NorthAm tie spacing for narrow guage).


It may not make sense at first...but it is pure mapping exercises that does take some time initially, but then the layout is inheritable and shareable. Where can I send you some zip files over the next couple of days rather than splash raw XML into a forum  ?

Cheers,

Victor


----------



## Brandon (Jul 6, 2011)

Posted By Brandon on 04 Jan 2012 02:12 PM
Thanks, responses make perfect sense.

As for question 2 regarding how handling model specs vs prototype specs are done I'm mostly curious about how handling of things that don't translate from one to the other, including hardware, software, and in RailML. A prototype can rely on fuel, being either electric or combustion, being relatively constant and thus performance reasonably constant. In your layouts in which trains use batteries how do you handle monitoring a model trains actual speed (to insure a train is actually going a scale 50mph) when a battery experiences voltage drop as the battery is used. What might start as 12.3v can become 11.9v under load and down to 10.3v under load and once most of the capacity of the battery has been used (numbers given as an example of course). Do you use voltage regulation and keep voltage below 10v to be safe in always having a set amount of voltage available or do you use vdc and monitor the current voltage being supplied by a battery and adjust the motor controller to average out at 10v? I'd have to assume you've done something in hardware and/or software and I'm curious if that work is represented in RailML for the layout. 


Edit: Yes, xml on forums wouldn't be as pretty... Since you have pm's turned off would you mind pming me your e-mail and I'll reply back with my e-mail address? I prefer to keep spam spiders busy hunting.


----------



## VictorSpear (Oct 19, 2011)

My teams, being intrinsically lazy (with high feet-dragging coefficients) don't seem to like to run after trains, swap batteries, yank JSTs or even open the trailing caboose after the first few weeks of a layout change. Since we supply a few kids hospitals with kits sponsored by donors, that's another reason to stay simple. So we use the brilliant and elegant Train UPS from Iptrains....constant voltage with intelligent charging. Only certain parts of the track siding reserved for charging, 2 to 3 feet. Most of the layout is non-powered track. The charging hut is a custom dog kennel in the hospital yard and the loco is simply shunted in automatically every 3 hours if they don't have an unoccupied charging siding. A voltage regulator also on board and the MCU requires 7.5V but consumes 45mA. The Xbee radios are on low power wake/sleep heartbeats. Trains run all day. 


Any idea why the Vimeo clip does not embed in the post ? I saw someone had done that quite successfully.


----------



## VictorSpear (Oct 19, 2011)

http://vimeo.com/34611697 --- with a RailML schema to keep up with daily requirements (changes) from kids.


----------



## Greg Elmassian (Jan 3, 2008)

How about some video of your ipod wireless interface? I saw a train in 3 modes, forward at fixed speed, reverse at fixed speed and stopped. 

By the way, you show all kinds of ship stuff, so I assumed you are on a boat of some kind? 

Greg


----------



## VictorSpear (Oct 19, 2011)

Yes, I've got a few to put up. Now that I've discovered Vimeo allows 500 Mb per week and that quota stays even if you delete the current clip ! So I got the Vimeo Plus now. 

The genius colleague who took the clip used his own iphone - that Stainz should be running slower in reverse than forward, but may not be noticeable on the cheap phone  The clips I have got are blotchy with shadow and reflections on the shiny touch screen and the GUIs show up fuzzy even on the HD 1080p - like the clunky touchscreen shots I've already posted. I'm need to get some better ones done this weekend or why pay for high res storage ?


Yes, I live at sea almost 10 months of the year.

Cheers
Victor


----------



## Greg Elmassian (Jan 3, 2008)

Yes, it was noticeable that reverse was slower. 

So, I'm curious, is this military? The consoles look like a commercial vessel, but I am not an expert. 

Greg


----------



## VictorSpear (Oct 19, 2011)

Research vessel. 

Kids showed me a way to get screen shots of anything on the phone with its own buttons. Didn't know it was there all along and great for emailing tech support at 3:00 am with an actual screenshot of the funky problem !
Life is good again.


----------



## Greg Elmassian (Jan 3, 2008)

Ahh, I used to do that, though not on the boat all the time... worked for NOAA... kind of... threw stuff in the water and measured some things and correlated with satellite data... 

Greg


----------



## VictorSpear (Oct 19, 2011)

We rely on those life-savers at NOAA on a daily basis.


----------



## VictorSpear (Oct 19, 2011)

It was a rain drenched weekend so it curtailed almost any of the outdoor light testing, but Tom (our process test engineer) and his 'crew' managed to get a couple of hours of 'everyday' life clips with the prior versions. 

They should be putting a vimeo up in a few hours , I believe.











Meanwhile, we added a 'Quick' tab with 3 buttons, and used a bizarre red and yellow-ochre combination - but the outdoor light was not bright so glare was not a factor yesterday.


----------



## VictorSpear (Oct 19, 2011)

Album is building ....http://vimeo.com/album/1799339


----------



## Greg Elmassian (Jan 3, 2008)

Looks good, the "quick" is the first interface I could say that makes sense for running when you are driving the train and need to pay attention. 

Now the speed might might go from the center and push up for more, and center and push down for less... you should be able to hit the direction and stop by just "feeling in from the end" of the phone. 

Maybe you could use motion to blow the whistle. If you can get stop, go, speed, direction, bell and whistle without looking that would work. 

Then, exit quick mode if you want more functions... you will want a way to eventually control more functions. 

Now, another idea: make this interface work with the JMRI WiThrottle server... why? because you can use it to develop and hone your interface without having to develop all the remote hardware right away 

Later, you can use your interface to control your custom hardware. 

This method also allows you to use DCC decoders and get a feel for all the functions you will want to control. 

Try making the "shake" command issues a grade crossing sequence. 

If you can do all this, then you might have a lot of people adopt your interface right off the bat. 

I would love to have an interface that could really work, and of course, the ability to customize the "controller" without hardware development costs is a boon to any product. 

Any chance of an Android version? 

Greg


----------



## VictorSpear (Oct 19, 2011)

_"I could say that makes sense for running when you are driving the train and need to pay attention. " _The Quick does make complete sense given the regular battle conditions with the kids+adults (bigger kids) around.



"the speed might might go from the center and push up for more, and center and push down for less." Speed from Center to top/bottom with Vertical Fader - good idea. Will test this weekend. 

_
_
_"hit the direction and stop by just "feeling in from the end" _- Also trying to get the phone vibrate function to trigger when this is touched. A beep would help I guess. 


"Maybe you could use motion to blow the whistle" - Brilliant idea - the accelerometer is built into the phone - need to use it more.

"_ make this interface work with the JMRI WiThrottle server.._" Good food for thought...need to look at this


"Try making the "shake" command issues a grade crossing sequence." - Can you pls elaborate more ?


"Android version" Was testing this a few weeks ago. It works with no change to the code..Wife, being an Apple junkie.. sent me an ipod touch so have to borrow one from the shipmates and test this weekend.


Cheers,
Victor


----------



## Greg Elmassian (Jan 3, 2008)

Vibration is actually better outdoors and in a show atmosphere, it's really noisy at shows, and if you are near a sound-equipped loco outside, an ack beep will be tough. Since you have to be holding the unit, the haptic feedback is better in my opinion. No matter really, can have both options and have it settable. 

It's a little more difficult to make very distinct motions to be recognized as different requests to the accelerometer, but I've been watching what has been happening in of all things, bluetooth headsets. 

So shaking the unit twice (2 separate quick bursts of movement/acceleration in opposite directions) is a nice distinct "command", and you could issue a command sequence for a grade crossing. 

The major thing people want to control sight unseen after the motion is sounds, and the whistle/horn is the top one. 

Regards, Greg


----------

