Ideas for reading scn file values

[SiameseCat]

Here's an idea I've had for reading the scn file on startup:
Loop through the entire scenario, split each string into key and line sections (like we do for Subsystems) and store these pairs in a map/hash_map. Then we can read the values from the dictionary in whatever order we want.

I think the biggest problem with this will be handling the parameters used by Orbiter. We could either send all strings read to ParseScenarioLineEx, or we could keep track of the keys used and let Orbiter handle any unused strings.

Any comments?

 

[Urwumpe]

Here's an idea I've had for reading the scn file on startup:
Loop through the entire scenario, split each string into key and line sections (like we do for Subsystems) and store these pairs in a map/hash_map. Then we can read the values from the dictionary in whatever order we want.

I think the biggest problem with this will be handling the parameters used by Orbiter. We could either send all strings read to ParseScenarioLineEx, or we could keep track of the keys used and let Orbiter handle any unused strings.

Any comments?

Is similar to my thoughts, but I would have suggested switching to a XML format, and build a tree structure in memory, if this wouldn't mean to again break the scenario file format. Using a tree structure would make it simpler to locate subsystems and also write sub-subsystem data into it, like sensors or I/O module states.

This way we could have some more control over the format, without needing to select which data to extract. <subsystems>...</subsystems> would get parsed as subsystem data, <panel>..</panel> as panel data, etc. all else would either be direct SSU flags or Orbiter data.

Also, I would suggest having a state template file for subsystems and panels, that is just using the same format as the data in the scenario, but can be loaded by a single scenario line. Eg, reading the switches and subsystems nominal state for starting orbit operations from such a file, etc.

 

[cinder1992]

I thought that there were already oAPI commands for that.

 

[Urwumpe]

I thought that there were already oAPI commands for that.

only for .cfg files

 

[SiameseCat]

Is similar to my thoughts, but I would have suggested switching to a XML format, and build a tree structure in memory, if this wouldn't mean to again break the scenario file format. Using a tree structure would make it simpler to locate subsystems and also write sub-subsystem data into it, like sensors or I/O module states.

This way we could have some more control over the format, without needing to select which data to extract. <subsystems>...</subsystems> would get parsed as subsystem data, <panel>..</panel> as panel data, etc. all else would either be direct SSU flags or Orbiter data.

Also, I would suggest having a state template file for subsystems and panels, that is just using the same format as the data in the scenario, but can be loaded by a single scenario line. Eg, reading the switches and subsystems nominal state for starting orbit operations from such a file, etc.

I'm not so fond of using XML in the scenario files. I'd prefer using the same system we have now and nesting subsytem, etc. blocks where required. There shouldn't be much difference programmatically and the file would look a lot cleaner, I think. Another thing we could do is have a separate block for SSU data, so Orbiter stuff would be the only section not in some kind of distinct block.

 

[Urwumpe]

I'm not so fond of using XML in the scenario files. I'd prefer using the same system we have now and nesting subsytem, etc. blocks where required. There shouldn't be much difference programmatically and the file would look a lot cleaner, I think. Another thing we could do is have a separate block for SSU data, so Orbiter stuff would be the only section not in some kind of distinct block.

I just suggest XML for the aspect, that there are complete XML readers around and finding bugs in our own code would be simpler then. Is not a must-have, but what should be needed IMHO are two new levels below the subsystem level:

- Failures, for describing planned or possible failures
- Subsubsystems or parts, which would make it simpler to construct the subsystems... eg pressure sensors or temperature sensors could be made single objects and integrated into subsystems, just like the shuttlebus and discrete signal parts.

The parts/failures stuff should also be available for VC components then, sharing the same code.

also, I would suggest some extensions for the (simple)GPCs: "@TASK" and "@COMPOOL".

Tasks are processes in the GPC, while COMPOOLs are shared memory locations. Most autopilot state data would for example end in the "GNC MF COMPOOL" or the "GNC OPS1 COMPOOL"

I have already the core FCOS COMPOOLs from the ALT, only still missing is the application data. The IOP would get stored as part then.

 

[SiameseCat]

I just suggest XML for the aspect, that there are complete XML readers around and finding bugs in our own code would be simpler then. Is not a must-have, but what should be needed IMHO are two new levels below the subsystem level:

- Failures, for describing planned or possible failures
- Subsubsystems or parts, which would make it simpler to construct the subsystems... eg pressure sensors or temperature sensors could be made single objects and integrated into subsystems, just like the shuttlebus and discrete signal parts.

The parts/failures stuff should also be available for VC components then, sharing the same code.

also, I would suggest some extensions for the (simple)GPCs: "@TASK" and "@COMPOOL".

Tasks are processes in the GPC, while COMPOOLs are shared memory locations. Most autopilot state data would for example end in the "GNC MF COMPOOL" or the "GNC OPS1 COMPOOL"

I have already the core FCOS COMPOOLs from the ALT, only still missing is the application data. The IOP would get stored as part then.

IMHO, the failures should be in the mission file - what I'm thinking is that the mission file contains all the data about the shuttle configuration and will never need to be changed. The scenario file reflects the current state of the shuttle. The scenario file will need to store which subsystems have actually failed.

Assuming we keep the current subsystem syntax, I don't think XML will be necessary. If you want to add additional features, using XML might be a good idea. Using XML will probably break existing scenarios, unless we just use it for the parts within the subsystem level.

 

[Urwumpe]

IMHO, the failures should be in the mission file - what I'm thinking is that the mission file contains all the data about the shuttle configuration and will never need to be changed. The scenario file reflects the current state of the shuttle. The scenario file will need to store which subsystems have actually failed.

True. My fault, have overseen this definition.

Assuming we keep the current subsystem syntax, I don't think XML will be necessary. If you want to add additional features, using XML might be a good idea. Using XML will probably break existing scenarios, unless we just use it for the parts within the subsystem level.

Yes, then let us keep the current one and just move the loading/saving of such data into a dedicated tree structure, instead of letting the subsystems handle it locally. The XML was just a suggestion for getting more standard.

 

[kuddel]

The XML was just a suggestion for getting more standard.

Hi there,
just my .5 EUR about this:

Take a look at JSON[1]
JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read[2] and write. It is easy for machines to parse and generate.
And it is 'standard'
BTW: lots of implementations are already available.

Cheers,
Peter

[1] http://www.json.org/
[2] something like this is "readable" and valid JSON:

{
  "system_a" : {
    "switch_a" : true,
    "switch_b" : 3.141,
    "switch_c" : "Hello world"
  },
  "system_b" : {
    "list" : [1, 4, 5, 6]
  }
}

 

[SiameseCat]

Using JSON wouldn't be any better than XML; it would still break existing scenarios, and we really don't need it.

 

[Urwumpe]

I must say, I like the C++ interface of JsonCpp,

http://jsoncpp.sourceforge.net

Something like that would be good in C++, but it doesn't really need to be JSON... But it is a more beautiful way to access data.

For example we could make a function:

void Subsystem::ReadState(const Json::Value& scn)
{
sm_temperature = scn["sm_temperature"].asDouble();
}

But that kind of stuff could also be done with the current format.

 

[SiameseCat]

Agreed, that syntax is nice. We could probably use a std::map to do the same thing. The main difficulty would be if the scenario didn't have the requested parameter.

 

[Urwumpe]

Agreed, that syntax is nice. We could probably use a std::map to do the same thing. The main difficulty would be if the scenario didn't have the requested parameter.

Yes, which is why using a Composite pattern like above would be safer compared to a std::map... because it already wraps the needed code for handling this case around it, and doesn't rely on a single level of hierarchy. Each subsystem could get its own subtree, which would act exactly like the big tree.

 

[SiameseCat]

You'd certainly want some kind of wrapper around whatever you're using to store the data (map, etc.) to handle these cases. The subsystem class would still need to figure out what value to use instead, though.

 

[Urwumpe]

You'd certainly want some kind of wrapper around whatever you're using to store the data (map, etc.) to handle these cases. The subsystem class would still need to figure out what value to use instead, though.

Yes, but it wouldn't be needed to limit this in advance. I don't think we can ensure having a scn format that will never be broken in the future. So, better have reading/writing the parameters as generic as possible, so at least this side of the I/O is as simple as possible.

 

[kuddel]

Each subsystem could get its own subtree, which would act exactly like the big tree.

That's exactly why I like JSON so much. You can build a hierarchical tree configuration without limits. And each (sub)component can therefore change the way it reads/writes that tree without breaking other configurations.
BTW: "JsonCpp" really is a nice C++ implementation of this.
Nevertheless, JSON is just *one* of many possibilities. And if I had known
that this would start such a discussion ...
Signing off,
Peter