search

openETCS / modeling

WP3 Top Level Project: to cover all tasks related with modeling
31 stars 42 forks source link

C API: how to send binary SRS message to Scade Model #893

Open didierersa opened 9 years ago

didierersa commented 9 years ago

Dear all,

We are currently in the process to decode/encode binary data to fill the Scade model with balise and radio data. As you may know, our tools use binary data that strictly follows the rules defined in chapter 7 and 8 of the SRS and since we are in charge of the gluecode we need to translate it to something that can be understood by the Scade.

To be sure we are doing the right things and because we cannot really test until almost every thing has been correctly coded decoded, may we ask you to confirm the process by looking above the pseudo code, especially can you confirm that we use the right API for the task:

Best regards, Didier

BerndHekele commented 9 years ago

In principle this comment is correct.

As an (more save) alternative, you could also maku use of the C - Types which are defined for each packet.

JakobGartner commented 9 years ago

This does not work universally.

The compression algorithm is a bit more complex than that as it needs to also provision for multiple packets of the same NID_PACKET (in case of operate packets per Q_DIR, in case of different version numbers from balise or RBC, in case of TSR or other packets that could occur more than once in a single message). In addition, packets with 2 levels of iterations (such as P27) break the packet into multiple virtual packets inside the Packet.Data and hence also need multiple entries in the metadata.

As Bernd says, the clean way would be to use the packets (Pxxx_trackside_int_t).

On 06 Nov 2015, at 10:37, didierersa notifications@github.com wrote:

Dear all,

We are currently in the process to decode/encode binary data to fill the Scade model with balise and radio data. As you may know, our tools use binary data that strictly follows the rules defined in chapter 7 and 8 of the SRS and since we are in charge of the gluecode we need to translate it to something that can be understood by the Scade.

To be sure we are doing the right things and because we cannot really test until almost every thing has been correctly coded decoded, may we ask you to confirm the process by looking above the pseudo code, especially can you confirm that we use the right API for the task:

for each telegram: decode telegram header (Q_UPDOWN, M_VERSION, ... Q_LINK) to API_fromTrack.btm_msg.api_header.* for each packet for each variable put decoded value in API_fromTrack.packets.PacketData[ Variable_Index ] end for put index of the first variable in API_fromTrack.packets.PacketHeaders[ Header_Index ].startAddress put index of the last variable in API_fromTrack.packets.PacketHeaders[ Header_Index ].endAddress end for if error then API_fromTrack.btm_msg.api_bad_balise_received = true end for Best regards, Didier

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/893.

didierersa commented 9 years ago

Sorry, I don't see how I can access to Pxxx_ as for now I only access scade model trough the interface defined in EVC.h:

/* EVC::EVCreset / kcg_bool _25_EVCreset, / EVC::APIOdometry / odometry_T_Obu_BasicTypes_Pkg APIOdometry, / EVC::APISystemTime / T_internal_Type_Obu_BasicTypes_Pkg APISystemTime, / EVC::APIfromTrack / API_TrackSideInput_T_API_Msg_Pkg APIfromTrack, / EVC::APIfromDMI / DMI_to_EVC_Message_int_T_API_DMI_Pkg APIfromDMI, / EVC::APIfromTIU / TIU_Input_msg_API_TIU_Pkg APIfromTIU, / EVC::APImobileHWStatus / mobileHWStatus_Type_MoRC_Pck APImobileHWStatus, / EVC::API_persistentData / ps_dataForStartOfMission_T_API_PersistanceStorage_Pkg *API_persistentData,

Can you point me with the proper API documentation or just give me an example how to send balise and radio message trough the API ?

JakobGartner commented 9 years ago

Bonjour Didier,

at the moment we have a library (contained in the model TrackMessages) that defines conversion functions for each packet, translating it from the integer-based format structured following Subset026_7 to the compressed format. If you just look at the at of the model for which you have received the code, you will not find them, as they are used in the trackside model to send the packets from RBC and/or balises.

As our track model is also done in SCADE, it is using these SCADE library operators for the data conversion.

There are now two possible ways to access them:

A typical type definition looks like this:

/* TM_baseline2::P027V1_trackside_sectionlist_T */ typedef array__1022 P027V1_trackside_sectionlist_T_TM_baseline2;

typedef struct { kcg_bool valid; kcg_int NID_PACKET; kcg_int Q_DIR; kcg_int L_PACKET; kcg_int Q_SCALE; kcg_int D_STATIC; kcg_int V_STATIC; kcg_int Q_FRONT; kcg_int N_ITER_n; P027V1_trackside_qdifflist_T_TM_baseline2 SECTIONS_q_diff; kcg_int N_ITER_k; P027V1_trackside_sectionlist_T_TM_baseline2 SECTIONS_SSP; } struct__1025;

Here I don’t have an example yet.

Jakob

On 06 Nov 2015, at 14:29, didierersa notifications@github.com wrote:

Sorry, I don't see how I can access to Pxxx_ as for now I only access scade model trough the interface defined in EVC.h:

/* EVC::EVC_reset / kcg_bool _25_EVC_reset, / EVC::API_Odometry / odometry_T_Obu_BasicTypes_Pkg API_Odometry, / EVC::API_SystemTime / T_internal_Type_Obu_BasicTypes_Pkg API_SystemTime, / EVC::API_fromTrack / API_TrackSideInput_T_API_Msg_Pkg API_fromTrack, / EVC::API_fromDMI / DMI_to_EVC_Message_int_T_API_DMI_Pkg API_fromDMI, / EVC::API_fromTIU / TIU_Input_msg_API_TIU_Pkg API_fromTIU, / EVC::API_mobileHWStatus / mobileHWStatus_Type_MoRC_Pck API_mobileHWStatus, / EVC::API_persistentData / ps_dataForStartOfMission_T_API_PersistanceStorage_Pkg *API_persistentData,

Can you point me with the proper API documentation or just give me an example how to send balise and radio message trough the API ?

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/893#issuecomment-154410078.

didierersa commented 9 years ago

Dear Jakob,

Could it be possible to have all the generated API functions (and a little example how to use them) together the whole scade model generated C code ? We don't have the accountability for choosing our self which models / packages should be exported or not and which one are compatible. I really think it is a task for WP3. As a customer of WP3, WP5 should take as is what is given, we should not interfere with the modeling and we should not "integrate" something that belongs to WP3.

We understand that you don't have time to develop a specific convenient api, but without sample and without documentation, it is very difficult for us to figure how the thing must be done as we don't have time to look deeply in the scade model to understand what possible mistake we might do.

An alternative would be that someone from WP3 help us making the bridge between scade and our tools inside the glue code, all that remains is to fill the scade data structure with what we already have decoded. We can post an update version of our glue/test env so we can work together.

If the operator from TrackMessages are simple enough it should be doable without much trouble.

Kind regards, Didier

MERCEmentre commented 8 years ago

Hello Jakob,

I'm trying to help Didier making the link between ERSA code and openETCS' EVC in SCADE, as WP3 participant.

From your comment 6 days ago, you would not have time to work on the 2nd alternative. So we need to work on the first one (using conversion functions defined in TrackMessages to convert from integer format to compressed format).

Now regarding the first alternative.

From a GitHub search (https://github.com/search?l=c&q=TM_baseline2%3A%3AP027V1_trackside_sectionlist_T&ref=searchresults&type=Code&utf8=%E2%9C%93), the TM_baseline2::P027V1_trackside_sectionlist_T you are taking as example is defined into several files, for example in: https://github.com/openETCS/srcAndBinary/blob/3c6e2d4f17fd9971ab0a80b1b71ccdf1a7ba8e7a/Green%20openETCS%20Non-Vital%20Demonstrator/Source%20Code/Source%20Code%20ETCS%20Track%20System/Generated_Code/AmsterdamUtrechtExpall/kcg_types.h#L405

So the needed types are defined in kcg_types.h (provided we now the right model to integrate amongst the several generated version of EVC), so far so good.

Now my next question is, where are the C/H files containing the operators your are referring to?

Again, doing a GitHub search (https://github.com/search?l=c&q=P027V1_trackside_sectionlist_T_TM_baseline2&ref=searchresults&type=Code&utf8=%E2%9C%93) I find the following file: https://github.com/openETCS/srcAndBinary/blob/ada877df99a17cea42b833d6230de629f6652d21/Green%20openETCS%20Non-Vital%20Demonstrator/MEN_demonstrator_stubs/Simulation/C_P027V1_tracksim_compr_body_TM_conversions_baseline2.h#L65

In this file there is reference to "C_P027V1_tracksim_compr_body_TM_conversions_baseline2()" function, matching I assume a SCADE operator. Is this this kind of function that we should use?

Could you give me then full name of a C file containing the C operator we need to use for proper setup of a balise message in appropriate compressed format?

Best regards, david

JakobGartner commented 8 years ago

Unfortunately this is a bit more complex, as the operators you would need are used inside the trackside model, but not exposed at the external interface. I will add a night shift (probably tomorrow) and build documentation for you and provide you with the right files.

On 12 Nov 2015, at 18:43, David MENTRE notifications@github.com wrote:

Hello Jakob,

I'm trying to help Didier making the link between ERSA code and openETCS' EVC in SCADE, as WP3 participant.

From your comment 6 days ago, you would not have time to work on the 2nd alternative. So we need to work on the first one (using conversion functions defined in TrackMessages to convert from integer format to compressed format).

Now regarding the first alternative.

From a GitHub search (https://github.com/search?l=c&q=TM_baseline2%3A%3AP027V1_trackside_sectionlist_T&ref=searchresults&type=Code&utf8=%E2%9C%93 https://github.com/search?l=c&q=TM_baseline2%3A%3AP027V1_trackside_sectionlist_T&ref=searchresults&type=Code&utf8=%E2%9C%93), the TM_baseline2::P027V1_trackside_sectionlist_T you are taking as example is defined into several files, for example in: https://github.com/openETCS/srcAndBinary/blob/3c6e2d4f17fd9971ab0a80b1b71ccdf1a7ba8e7a/Green%20openETCS%20Non-Vital%20Demonstrator/Source%20Code/Source%20Code%20ETCS%20Track%20System/Generated_Code/AmsterdamUtrechtExpall/kcg_types.h#L405 https://github.com/openETCS/srcAndBinary/blob/3c6e2d4f17fd9971ab0a80b1b71ccdf1a7ba8e7a/Green%20openETCS%20Non-Vital%20Demonstrator/Source%20Code/Source%20Code%20ETCS%20Track%20System/Generated_Code/AmsterdamUtrechtExpall/kcg_types.h#L405 So the needed types are defined in kcg_types.h (provided we now the right model to integrate amongst the several generated version of EVC), so far so good.

Now my next question is, where are the C/H files containing the operators your are referring to?

Again, doing a GitHub search (https://github.com/search?l=c&q=P027V1_trackside_sectionlist_T_TM_baseline2&ref=searchresults&type=Code&utf8=%E2%9C%93 https://github.com/search?l=c&q=P027V1_trackside_sectionlist_T_TM_baseline2&ref=searchresults&type=Code&utf8=%E2%9C%93) I find the following file: https://github.com/openETCS/srcAndBinary/blob/ada877df99a17cea42b833d6230de629f6652d21/Green%20openETCS%20Non-Vital%20Demonstrator/MEN_demonstrator_stubs/Simulation/C_P027V1_tracksim_compr_body_TM_conversions_baseline2.h#L65 https://github.com/openETCS/srcAndBinary/blob/ada877df99a17cea42b833d6230de629f6652d21/Green%20openETCS%20Non-Vital%20Demonstrator/MEN_demonstrator_stubs/Simulation/C_P027V1_tracksim_compr_body_TM_conversions_baseline2.h#L65 In this file there is reference to "C_P027V1_tracksim_compr_body_TM_conversions_baseline2()" function, matching I assume a SCADE operator. Is this this kind of function that we should use?

Could you give me then full name of a C file containing the C operator we need to use for proper setup of a balise message in appropriate compressed format?

Best regards, david

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/893#issuecomment-156180348.

MERCEmentre commented 8 years ago

Thanks Jakob! I'm looking forward for your further inputs.

JakobGartner commented 8 years ago

Hello David,

hello Didier,

I have spent some time on the weekend thinking about how to best point you to building a connection with limited integration risk- and work.

A generic API is possible, I know how to do it, but it would take me about 1 week of work which we don’t have. Pity you didn’t ask earlier.

I have provided two examples for “rough and dirty API” in srcAndBinary/API_for_ERSA.

The interfaces should be rather self-explaining if you start looking from “Send_message_003_API_Examples” and “SEND_MergeRadioPackets_TM_old_versions”, respectively.

Jakob

On 12 Nov 2015, at 18:43, David MENTRE notifications@github.com wrote:

Hello Jakob,

I'm trying to help Didier making the link between ERSA code and openETCS' EVC in SCADE, as WP3 participant.

From your comment 6 days ago, you would not have time to work on the 2nd alternative. So we need to work on the first one (using conversion functions defined in TrackMessages to convert from integer format to compressed format).

Now regarding the first alternative.

From a GitHub search (https://github.com/search?l=c&q=TM_baseline2%3A%3AP027V1_trackside_sectionlist_T&ref=searchresults&type=Code&utf8=%E2%9C%93 https://github.com/search?l=c&q=TM_baseline2%3A%3AP027V1_trackside_sectionlist_T&ref=searchresults&type=Code&utf8=%E2%9C%93), the TM_baseline2::P027V1_trackside_sectionlist_T you are taking as example is defined into several files, for example in: https://github.com/openETCS/srcAndBinary/blob/3c6e2d4f17fd9971ab0a80b1b71ccdf1a7ba8e7a/Green%20openETCS%20Non-Vital%20Demonstrator/Source%20Code/Source%20Code%20ETCS%20Track%20System/Generated_Code/AmsterdamUtrechtExpall/kcg_types.h#L405 https://github.com/openETCS/srcAndBinary/blob/3c6e2d4f17fd9971ab0a80b1b71ccdf1a7ba8e7a/Green%20openETCS%20Non-Vital%20Demonstrator/Source%20Code/Source%20Code%20ETCS%20Track%20System/Generated_Code/AmsterdamUtrechtExpall/kcg_types.h#L405 So the needed types are defined in kcg_types.h (provided we now the right model to integrate amongst the several generated version of EVC), so far so good.

Now my next question is, where are the C/H files containing the operators your are referring to?

Again, doing a GitHub search (https://github.com/search?l=c&q=P027V1_trackside_sectionlist_T_TM_baseline2&ref=searchresults&type=Code&utf8=%E2%9C%93 https://github.com/search?l=c&q=P027V1_trackside_sectionlist_T_TM_baseline2&ref=searchresults&type=Code&utf8=%E2%9C%93) I find the following file: https://github.com/openETCS/srcAndBinary/blob/ada877df99a17cea42b833d6230de629f6652d21/Green%20openETCS%20Non-Vital%20Demonstrator/MEN_demonstrator_stubs/Simulation/C_P027V1_tracksim_compr_body_TM_conversions_baseline2.h#L65 https://github.com/openETCS/srcAndBinary/blob/ada877df99a17cea42b833d6230de629f6652d21/Green%20openETCS%20Non-Vital%20Demonstrator/MEN_demonstrator_stubs/Simulation/C_P027V1_tracksim_compr_body_TM_conversions_baseline2.h#L65 In this file there is reference to "C_P027V1_tracksim_compr_body_TM_conversions_baseline2()" function, matching I assume a SCADE operator. Is this this kind of function that we should use?

Could you give me then full name of a C file containing the C operator we need to use for proper setup of a balise message in appropriate compressed format?

Best regards, david

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/893#issuecomment-156180348.

didierersa commented 8 years ago

Unfortunately, we started our integration / glue code with the odometry and TIU which have well defined (and quite simple...) interfaces, so we didn't tough balise and radio messages will be so different.

Anyway, I guess you're last push on github should do the job, we will have a look at this ASAP. We really hope we will have time to integrate it.

Thank you very much.

JakobGartner commented 8 years ago

you must tell me which option you need, because right now i only pushed examples that are not complete. Some work from my side will be required.

On 16 Nov 2015, at 12:05, didierersa notifications@github.com wrote:

Unfortunately, we started our integration / glue code with the odometry and TIU which have well defined (and quite simple...) interfaces, so we didn't tough balise and radio messages will be so different.

Anyway, I guess you're last push on github should do the job, we will have a look at this ASAP. We really hope we will have time to integrate it.

Thank you very much.

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/893#issuecomment-156995662.

MERCEmentre commented 8 years ago

Hello Jacob,

Where have you pushed those two examples? Right now I don't see them in modeling/ repo: https://github.com/openETCS/modeling/commits/master?author=JakobGartner

Oops sorry, found it: https://github.com/openETCS/srcAndBinary/tree/master/API_for_ERSa/KCG-ERSA

Best regards, david

JakobGartner commented 8 years ago

https://github.com/openETCS/srcAndBinary/commit/cff1c097782d47d18dc824237d69d19cc71496d3

On 16 Nov 2015, at 12:11, David MENTRE notifications@github.com wrote:

Hello Jacob,

Where have you pushed those two examples? Right now I don't see them in modeling/ repo: https://github.com/openETCS/modeling/commits/master?author=JakobGartner https://github.com/openETCS/modeling/commits/master?author=JakobGartner Best regards, david

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/893#issuecomment-156998478.

MERCEmentre commented 8 years ago

Thanks Jacob, found it afterwards. I'm currently looking at your examples. I'll probably have some questions this afternoon.

didierersa commented 8 years ago

Hello Jakob, hello David

I guess the messages in chapter 8 are only for radio messages, so I'm not sure the second option will apply well for balise telegrams as a "packet" oriented API may be more suited for the task.

It may require more work, because Scade model should check whenever a packet is valid or not for a given message (ad thus must know which message we are decoding..). The glue code should not implement anything of the subset 26.

Maybe David will also have an opinion about it, but for now I prefer the first solution, although open about the discussion.

JakobGartner commented 8 years ago

ok, the first solution is also more easy for me.

The only disadvantage is that it has additional overhead and is less modular when it comes to multiple packets of the same type.

When you are sure, I will complete it to support all packet types that may occur on our use cases.

In the second solution, there is some check as you mention.

Anyway, only valid messages are decoded (others are ignored)

This you don’t see as what you see is only the “sending” part. It is on the EVC side that messages are checked for consistency etc.

J

On 16 Nov 2015, at 14:04, didierersa notifications@github.com wrote:

Hello Jakob, hello David

I guess the messages in chapter 8 are only for radio messages, so I'm not sure the second option will apply well for balise messages as a "packet" oriented API may be more suited for the task.

It may require more work, because Scade model should check whenever a packet is valid or not for a given message (ad thus must know which message we are decoding..). The glue code should not implement anything of the subset 26.

Maybe David will also have an opinion about it, but for now I prefer the first solution, although open about the discussion.

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/893#issuecomment-157022902.

didierersa commented 8 years ago

I would say, as for now I cannot see how use the second API in case of a balise telegram as there is no "messages" (or I didn't fully understood your proposal), so let's go with solution 1. Maybe you can start with the packet needed (mandatory) for the user stories.

JakobGartner commented 8 years ago

The packet part is identical for balises and for RBC. The message part is different.

Hence the second solution can also be adapted for balises.

The first solution can also be enriched to port the message input as example 2.

The main difference between the 1st and 2nd proposal is that the first one allows to add any packet to any message type, making it more general. In consequence it is much easier for me to build it. The second combines only packets that are valid for a given message type.

To make it more clear, I will push the 1st version in a balise and in a RBC flavour.

Jakob

On 16 Nov 2015, at 14:24, didierersa notifications@github.com wrote:

I would say, as for now I cannot see how use the first API in case of a balise telegram as there is no "messages" (or I didn't fully understood your proposal), so let's go with solution 2. Maybe you can start with the packet needed (mandatory) for the user stories.

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/893#issuecomment-157026329.

didierersa commented 8 years ago

Ok, Let go for it.

BTW, the genericity of the first solution may allow us to keep the api unchanged, even in case of future message for future version (3.4.x / 3.5.x)

Many thanks for your help..

MERCEmentre commented 8 years ago

Hello Jakob and Didier,

Some parts are currently unclear to me so it is difficult for me to make a choice, but if Didier is preferring the first approach it is OK for me, especially if it is easier for you Jakob.

Best regards, david

JakobGartner commented 8 years ago

Hello Didier, David

I have pushed a (non-generic for now) example how in principle a balise telegram would look like. (subfolder in same repo)

If you agree, I would

Remark: The real “generic” API would look very different, as it will take a flat array of data, analog to the bilevel defined in SRS. There you would only have to transform the bitfield to a flat numeric array (probably then also in BCD encoding)- This would allow for full flexibility and avoid rolling in and out the sections (N_ITER)

But, as I said, I will not have the time now.

Jakob

On 16 Nov 2015, at 14:45, didierersa notifications@github.com wrote:

Ok, Let go for it.

BTW, the genericity of the first solution may allow us to keep the api unchanged, even in case of future message for future version (3.4.x / 3.5.x)

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/893#issuecomment-157030416.

didierersa commented 8 years ago

I've just checked the code and I guess a solution based on it should be usable for us.

Of course, a fully generic api like you proposed would have been better and safer because the decoding part is not trivial and would have been a good candidate for formal methods. Maybe for the future...

Didier,

JakobGartner commented 8 years ago

The generic version will come in any case, but out of scope for this project.

On 16 Nov 2015, at 15:10, didierersa notifications@github.com wrote:

I've just checked the code and I guess a solution based on it should be usable for us.

Of course, a fully generic api like you proposed would have been better and safer because the decoding part is not trivial and would have been a good candidate for formal methods. Maybe for the future...

Didier,

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/893#issuecomment-157041182.

JakobGartner commented 8 years ago

I have posted a version of API fronted code that we could call semi- generic.

There are 3 folders:

radio_semigeneric: to send RBC messages with related packets

the interface is described in “API_Frontend_radio_prelim_TM_API.h”

The input

M_TrackTrain_Radio_T_TM_radio_messages /* TM_API::API_Frontend_radio_prelim::message_header */ message_header;

is generic. It receives data for any message as described in Subset026 chapter 8. Checking and decoding is handled by the model.

The mappings look like this: (see attached file: Messages type definitions)

API_ERSA.pdf

you must just fill the input related to the messages according to the definitions illustrated and stuff the rest with zeros.

If you only send only maximum one packet per type in a given message, please set the input CompressedPackets_T_Common_Types_Pkg /* TM_API::API_Frontend_radio_prelim::packets_in */ packets_in; to invalid, by using a constant value that sets the metadata to invalid, this is done by setting the "valid" flags to "false".

balise_semigeneric: to send Balise telegrams with header + packets

If you only send only maximum one packet per type in a given message, please set the input CompressedPackets_T_Common_Types_Pkg /* TM_API::API_Frontend_radio_prelim::packets_in */ packets_in; to invalid, by using a constant value that sets the metadata to invalid, this is done by setting the "valid" flags to "false".

the interface is described in “API_Frontend_balises_prelim_TM_API.h”

additional_packets: to send packets if there is more than one instance of any packet in a message or telegram

the interface is described in “SEND_MergePackets_TM_API”

if you use this function, connect its output to the packets input if the send radio/ send balise telegram functions .

JakobGartner commented 8 years ago

This interface is quite limited and not very flexible, but its what I could do quickly.

JakobGartner commented 8 years ago

there is another issue: NID_LRBG is not encoded according to the SRS (on binary level) but just by concatenating two integers into one in the form CCCCBBBBB. where C=NID_C and B=NID_BG. On C, leading 0 are omitted, on B, leading 0 are stuffed. Also, values requiring BCD encoding are also just encoded to integer with leads to non- correct coding in some cases. This is due to the fact that we had to digest decoded JRU data where this was done this way, too.

didierersa commented 8 years ago

Ok, I will try to integrate it tomorrow, I will come back here if I encounter anything blocking for us. Thank you.

didierersa commented 8 years ago

Dear all,

The main problem I face is the multiple occurrence of kcg_const.h, kcg_types.h, kcg_xxx.h, which leads to multiple definition of same symbols. For us, we really need one codebase, with everything that we need correctly glued together. We cannot merge multiple source and hope that there will be no conflicts. While promising, this new interface require too much work until everything is generated in a single shot. It cannot be WP5 job to integrate the source from:

jokaICS commented 8 years ago

Who told you to use srcAndBinary/Simulation_EnvSim/?

didierersa commented 8 years ago

sorry I mean https://github.com/openETCS/modeling/tree/master/test/EnvSim/libenvsim

jokaICS commented 8 years ago

Well, our utility source code structure was not specifically tailored for non-WP3 demonstrators. libenvsim was originally intended to be used only within WP3. We can provide you with binary versions of libenvsim, but considering the deadline moving closer rapidly, I have no time to restructure the sources -- sorry.

MERCEmentre commented 8 years ago

To complete Didier's remarks, I also agree that having several kcg_const.h, kcg_types.h, ... might lead to difficult to track bugs. There could be clash on kcg's generated symbol names. I currently trying to integrate balise_semigeneric/ into ERSA's evcglue code but I have to make several header file renames.

One solution for this would be for @JakobGartner (or other relevant people) to include definition of balise_semigeneric/, radio_semigeneric/ and additional_packets/ SCADE symbols into the same SCADE project as EVC, so that all C code would be generated in a coherent manner (i.e. along https://github.com/openETCS/srcAndBinary/tree/master/Green%20openETCS%20Non-Vital%20Demonstrator/Source%20Code/Source%20Code%20ETCS%20Onboard%20Unit%20System/Generated_Code/KCG-ERSA). Would it be doable at a reasonable cost?

MERCEmentre commented 8 years ago

OK, to confirm that current integration of balise_semigeneric/, radio_semigeneric/ and additional_packets/ is a real issue in current code, I have a concrete example where a type is redefined. For the context, I have included balise_semigeneric/ code into ERSA's evcglue code, prefixing balisesemigeneric/ `kcgheaders withbalise_semigenerickcg`:

In file included from include/API_Frontend_balises_prelim_TM_API.h:8:0,
                 from src/EGDE_Decoder.c:6:
include/balise_semigeneric_kcg_types.h:54:3: error: redeclaration of enumerator ‘Q_DIR_Reverse’
   Q_DIR_Reverse = 0,
   ^
In file included from include/EGDE_Decoder.h:42:0,
                 from src/EGDE_Decoder.c:3:
../scade/kcg_types.h:947:3: note: previous definition of ‘Q_DIR_Reverse’ was here
   Q_DIR_Reverse = 0,
   ^

In above example, Q_DIR_Reverse is defined both in scade/kcg_types.h and balise_semigeneric_kcg_types.h.

The definition is the same, so we could manually remove this definition in one of the files. But overall such an approach seems very error prone to me.

What do you think of it?

MERCEmentre commented 8 years ago

List of conflicting types (for balise_semigeneric/):

include/balise_semigeneric_kcg_types.h:54:3: error: redeclaration of enumerator ‘Q_DIR_Reverse’
include/balise_semigeneric_kcg_types.h:55:3: error: redeclaration of enumerator ‘Q_DIR_Nominal’
include/balise_semigeneric_kcg_types.h:56:3: error: redeclaration of enumerator ‘Q_DIR_Both_directions’
include/balise_semigeneric_kcg_types.h:57:3: error: conflicting types for ‘Q_DIR’
include/balise_semigeneric_kcg_types.h:59:17: error: redefinition of typedef ‘NID_PACKET’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:62:17: error: redefinition of typedef ‘nid_packet_meta_TM’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:77:17: error: redefinition of typedef ‘array_int_255’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:154:17: error: redefinition of typedef ‘array_int_32’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:191:17: error: redefinition of typedef ‘array_int_500’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:194:23: error: redefinition of typedef ‘CompressedPacketData_T_Common_Types_Pkg’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:205:23: error: conflicting types for ‘MetadataElement_T_Common_Types_Pkg’
include/balise_semigeneric_kcg_types.h:210:22: error: conflicting types for ‘Metadata_T_Common_Types_Pkg’
include/balise_semigeneric_kcg_types.h:218:23: error: conflicting types for ‘CompressedPackets_T_Common_Types_Pkg’
include/balise_semigeneric_kcg_types.h:627:23: error: conflicting types for ‘P042_trackside_int_T_TM’
include/balise_semigeneric_kcg_types.h:816:17: error: redefinition of typedef ‘array_int_64’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:819:22: error: redefinition of typedef ‘P058_sections_array_flat_T_TM’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:822:22: error: redefinition of typedef ‘P027V1_sections_array_flat_qdiff_T_TM_baseline2’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:824:17: error: redefinition of typedef ‘array_int_2’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:853:17: error: redefinition of typedef ‘array_int_6’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:863:17: error: redefinition of typedef ‘array_int_66’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:866:22: error: redefinition of typedef ‘P046_sections_array_flat_T_TM’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:878:17: error: redefinition of typedef ‘array_int_99’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:881:22: error: redefinition of typedef ‘P021_sections_array_flat_T_TM’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:884:22: error: redefinition of typedef ‘P041_sections_array_flat_T_TM’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:891:17: error: redefinition of typedef ‘array_int_3’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:912:17: error: redefinition of typedef ‘array_int_128’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:915:23: error: redefinition of typedef ‘P015_sections_array_flat_T_TM’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:917:17: error: redefinition of typedef ‘array_int_4’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:927:17: error: redefinition of typedef ‘array_int_231’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:930:23: error: redefinition of typedef ‘P005_sections_array_flat_T_TM’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:937:17: error: redefinition of typedef ‘array_int_7’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:955:17: error: redefinition of typedef ‘array_int_1’ [-Wpedantic]
include/balise_semigeneric_kcg_types.h:1991:0: error: "kcg_comp_CompressedPackets_T_Common_Types_Pkg" redefined
include/balise_semigeneric_kcg_types.h:1993:0: error: "kcg_copy_CompressedPackets_T_Common_Types_Pkg" redefined
include/balise_semigeneric_kcg_types.h:1999:0: error: "kcg_comp_MetadataElement_T_Common_Types_Pkg" redefined
include/balise_semigeneric_kcg_types.h:2001:0: error: "kcg_copy_MetadataElement_T_Common_Types_Pkg" redefined
include/balise_semigeneric_kcg_types.h:2003:0: error: "kcg_comp_Metadata_T_Common_Types_Pkg" redefined
include/balise_semigeneric_kcg_types.h:2005:0: error: "kcg_copy_Metadata_T_Common_Types_Pkg" redefined
include/balise_semigeneric_kcg_types.h:2219:0: error: "kcg_comp_P042_trackside_int_T_TM" redefined
include/balise_semigeneric_kcg_types.h:2221:0: error: "kcg_copy_P042_trackside_int_T_TM" redefined

For example, the last two ones could be incompatible structures (kcg_comp_struct51075 vs. kcg_comp_struct106095):

In file included from include/API_Frontend_balises_prelim_TM_API.h:8:0,
                 from src/EGDE_Decoder.c:6:
include/balise_semigeneric_kcg_types.h:2219:0: error: "kcg_comp_P042_trackside_int_T_TM" redefined
 #define kcg_comp_P042_trackside_int_T_TM kcg_comp_struct__51075
 ^
In file included from include/EGDE_Decoder.h:42:0,
                 from src/EGDE_Decoder.c:3:
../scade/kcg_types.h:11334:0: note: this is the location of the previous definition
 #define kcg_comp_P042_trackside_int_T_TM kcg_comp_struct__106095
 ^
JakobGartner commented 8 years ago

Hello

Building a specific version of the openETCS EVC model that includes the interface I proposed is the only clean solution to this problem (unless we build separate DLLs and link them).

I published the interface to you first, so that you can assess it (and also possibly do first integrations for test purposes) without having to cope with the full EVC code.

We will work with ERSA next week and will provide an integration. The cost on SCADE level effort is very low.

Jakob + +

On 20 Nov 2015, at 12:32, David MENTRE notifications@github.com wrote:

To complete Didier's remarks, I also agree that having several kcg_const.h, kcg_types.h, ... might lead to difficult to track bugs. There could be clash on kcg's generated symbol names. I currently trying to integrate balise_semigeneric/ into ERSA's evcglue code but I have to make several header file renames.

One solution for this would be for @JakobGartner https://github.com/JakobGartner (or other relevant people) to include definition of balise_semigeneric/, radio_semigeneric/ and additional_packets/ SCADE symbols into the same SCADE project as EVC, so that all C code would be generated in a coherent manner (i.e. along https://github.com/openETCS/srcAndBinary/tree/master/Green%20openETCS%20Non-Vital%20Demonstrator/Source%20Code/Source%20Code%20ETCS%20Onboard%20Unit%20System/Generated_Code/KCG-ERSA https://github.com/openETCS/srcAndBinary/tree/master/Green%20openETCS%20Non-Vital%20Demonstrator/Source%20Code/Source%20Code%20ETCS%20Onboard%20Unit%20System/Generated_Code/KCG-ERSA). Would it be doable at a reasonable cost?

— Reply to this email directly or view it on GitHub https://github.com/openETCS/modeling/issues/893#issuecomment-158368826.

JakobGartner commented 8 years ago

Transferred to Stefan who is working on the integration with ERSA