crocal

We did use actual data from existing lines to measure the gap between our models and reality. We were +/- 5% accurate.

Ahoi! Participated to the development of a simulation tool for that purpose. Many factors need to be taken into account:

- The gradients of the track

- How agressively you want to drive at different time of the day

- How many trains

- The timing of the trains. When one train brakes, it can power another one that accelerates at the same moment

- The efficiency of the power chain

- The resistance model of the train

With so many parameters the results can be quite volatile. However, rule of the thumb in the business is that 30% saving can be achieved with good energy management. Hope this clarifies a little.

Update: bullet points

What else is new? This was already well known among grad students in the late 90s. We even knew there was some kind of hierarchy, with one of the student acting as «political officer».

Unrelated question: how did you manage tabular data in git? It’s always a struggle to diff and merge changes.

I will just chime in to mention Draftable (https://www.draftable.com/compare). It really works well. It’s not so easy to have a visually comfortable diff of two PDFs.

Well. First, the goal is precisely to remove wayside balises and replace them with gnss for resetting of the absolute loc. You can parse the last section of this: https://www.ct5webapi.eu/api/documents/getfile?id=a5aa9e2b-e...

Second, in a war-like scenario, do we really want to have our critical infrastructures unable to operate at full capacity?

The sequel: https://www.clug2.eu/

Sure thing: http://clugproject.eu/en (Edit: they even have a 2.0, see my sibbling comment)

Except the stated goal here is to replace these sensors with GPS.

I cannot agree more with the author’s point of view. As an illustration, many people want to use GPS for the safe positioning of trains in the European Train Control Systems. This makes the space sector happy because it justifies the expenditures incurred for putting things like Galileo in orbit. However, in a pre-war check exercise, one immediately come to the conclusion that all European trains would crawl to a stop in case the GPS is jammed or interfered with. We were not very listened to… until Ukraine.

Critical infrastructures should not depend from things that are located in space or on the other side of the planet. These are one of those things were market logic should be anticipated with regulations (we can’t wait for the next Titanic). Another point touched by the article.

I concur. I broke my wrist.

This correct. Power lines wear induced by pantographs is the limiting factor for TGV top speed.

The engineer that can solve this problem will allow top speeds in the range of 400/500 kph on /existing/ TGV tracks. Much better problem to solve than hacking a lame hyperloop.

There is something very wrong going on in Germany AND France where, despite the nice speeches, investment in railway infrastructure is being run into the ground. If nothing changes, expect disaster-level quality of service within a 5 years time.

FYI, this has been done: https://compcert.org/

He probably used this template: https://youtu.be/f37K0hIv3zk

You have to live in a world where there is no Netflix and no Disney/Pixar yet. Where the standard for mass-media japanimation is Dragon Ball Z. People had to wait for each episode for days if not weeks. At that point in time Ideaki Anno was a name only known to relatively few people, but we knew he could deliver stellar stuff. Evangelion started hyper-well animated and characters resonated with many viewers. Cool music too. The story arc looked promising with dark brooding villains and misteries everywhere. It was really something at the time. Where it ended is another (controversial) story.

No matter what you call it the ruling class will always call the tune and the poor and middle class will dance.

Ever heard about the French revolution? Ruling class had to take dance lessons.

Smart and productive people are happiest when they are free to do whatever they feel is worthy of their time and attention. One of the key to their productivity is that they don’t need to be told what to do every step of the way. Retire at 30 does not mean being unproductive, it means working on what you want, when you want. I have even met execs in large orgs that were essentially doing the job because they liked it. They did not need the salary anymore.

The behaviour described in the article makes me think of a goal-oriented AI. It does not require a lot of complexity and can exhibit very advanced and quite surprising behaviour.

Dude. TI-81 was my high school calculator. I got pretty famous at some point for managing to squeeze into it a decent RPG with monsters, health points and some story line. Other geeks were jealous and jocks patted me on the back for providing distraction. The challenge was the available BASIC program memory. We spent the next few months figuring out how to reduce the footprint to the bare minimum to add more gameplay. No internet at the time. Just our brains and the manuals. I chuckle at the idea of what we could have done if we had been hinted access to assembly and pixel flicker tricks to have 4 colours.

EDIT: Typos

Negative in my case. It’s functioning properly.

The point seems missed to me. Like any serious collaborative undertaking (movies, buildings, complex systems development, scientific collaborations, etc), successful software needs a unique person to carry the vision of what is the expected result and do what needs to be done to achieve this result, including organizing the works. Call him or her a director, an architect, a chief scientist, a hero… He/she will always be needed.

It’s interesting to note that these people can also become the doom of the project. This is why there is no single easy recipe for picking the right person.

Same thing.

As a trainee I was helping a crew supervise a power plant in charge of providing superheated steam to a large nuclear facility.

There was a bronze plaque on the ground in one of the technical room where some guys had been cooked alive.

Superheated steam and boilers scare the hell out of me.

This is the precise point of the famous article by Leslie Lamport on time, clocks and the ordering of events in a distributed system. I was surprised that it was not mentioned in this article, as it formalizes the link between this fact and the relativity of time.

Crossrail is legendary in the field as the example of what not to do when managing mega projects.

What I was told by greybeards: systems engineering was non-existent and rushed to the « let’s start to concrete » phase. When the project started to install the various systems, all hell broke loose. For example, systems had to be taken in, then out, because they just didn’t work in the field.

Side note: which makes this article really a good laugh. Who cares if your virtual model works if it does not in the real world?

OK so, that would not have been too bad if the management of the mega project would just have recognized the fuck up and declared delays. Instead, it scrambled to find ways to recuperate the accumulating delays, while reporting green to the politicians. As usual, a cretin came into the room to suggest that signalling tests could be compressed down and commissioning tests could proceed while construction completed the remaining work.

Problem: crossrail decided to experiment with a new hybrid signalling system that uses two different types of train control in order to maximize throughput in central london area. That turned an already rotten idea into an impossible one. Situation in the fields became insane. Signalling contractor shot a letter to cover ass. Politicians finally noticed, and sent clueless consultants to investigate, therefore opening the gates of hell.

Aaaaah. I like the scent of Napalm in the tunnels.

EDIT: typos

It was summer 99. I was finishing my CompSci MS degree in US. I was driving back from visiting DC with my future wife in my Oldsmobile ‘84 Cutlass Supreme (a.k.a. wreck on wheels). The day was so hot the radiator exploded, so we waited in a diner until the night fell and we could ride in cooler air. A guy and his family parked next to us. His car was also bust. It was a Yahoo guy. 15 minutes later I had a friggin’ job offer in my back pocket, as we rode toward the setting sun.

Those were the days.

Just because A occurs before B in « wall clock » time does not mean they are causally related.

Your point is wrong. C was /not/ intended for safety critical applications. Therefore, it makes sense that using it in that context will require adaptation.

For Ada it does not. It’s tire patching.

C and C++ were not designed with critical applications in mind. Therefore you cannot apply the same criticism to them.

SPARK is a proof that something is wrong. If you have to restrict the language to attain the goal of the language, that’s a bad place to be.

Furthermore, as you have stated, such « safe » subsets can be defined for other languages like C or C++. Once you have that, why struggle hiring or training rare Ada developers?

Both dynamics are bringing Ada adoption to a stop. It may be a shame but that’s what I see.

Ada is really in a bad place. It’s too generalist for safety critical applications. A DSL is a much better fit, restricting operations and possible side effects to a minimum. At the same time, it’s very abstract and somewhat esoteric, meaning capable developers and tools are hard to find. Everywhere I look it is replaced by something else.