{"action":"created","issue":{"url":"https://api.github.com/repos/openETCS/modeling/issues/646","labels_url":"https://api.github.com/repos/openETCS/modeling/issues/646/labels{/name}","comments_url":"https://api.github.com/repos/openETCS/modeling/issues/646/comments","events_url":"https://api.github.com/repos/openETCS/modeling/issues/646/events","html_url":"https://github.com/openETCS/modeling/issues/646","id":99912889,"number":646,"title":"InformationFilter: When working on Msg 3 : Concept of Delayed Messages does not fit to the use-case","user":{"login":"BerndHekele","id":3288918,"avatar_url":"https://avatars.githubusercontent.com/u/3288918?v=3","gravatar_id":"","url":"https://api.github.com/users/BerndHekele","html_url":"https://github.com/BerndHekele","followers_url":"https://api.github.com/users/BerndHekele/followers","following_url":"https://api.github.com/users/BerndHekele/following{/other_user}","gists_url":"https://api.github.com/users/BerndHekele/gists{/gist_id}","starred_url":"https://api.github.com/users/BerndHekele/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/BerndHekele/subscriptions","organizations_url":"https://api.github.com/users/BerndHekele/orgs","repos_url":"https://api.github.com/users/BerndHekele/repos","events_url":"https://api.github.com/users/BerndHekele/events{/privacy}","received_events_url":"https://api.github.com/users/BerndHekele/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/openETCS/modeling/labels/bug","name":"bug","color":"fc2929"},{"url":"https://api.github.com/repos/openETCS/modeling/labels/bug%20in%20Integration","name":"bug in Integration","color":"e11d21"}],"state":"open","locked":false,"assignee":{"login":"BerndHekele","id":3288918,"avatar_url":"https://avatars.githubusercontent.com/u/3288918?v=3","gravatar_id":"","url":"https://api.github.com/users/BerndHekele","html_url":"https://github.com/BerndHekele","followers_url":"https://api.github.com/users/BerndHekele/followers","following_url":"https://api.github.com/users/BerndHekele/following{/other_user}","gists_url":"https://api.github.com/users/BerndHekele/gists{/gist_id}","starred_url":"https://api.github.com/users/BerndHekele/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/BerndHekele/subscriptions","organizations_url":"https://api.github.com/users/BerndHekele/orgs","repos_url":"https://api.github.com/users/BerndHekele/repos","events_url":"https://api.github.com/users/BerndHekele/events{/privacy}","received_events_url":"https://api.github.com/users/BerndHekele/received_events","type":"User","site_admin":false},"milestone":null,"comments":12,"created_at":"2015-08-09T16:48:24Z","updated_at":"2015-08-10T08:28:23Z","closed_at":null,"body":"When analysing the information filter we had a long discussion on whether complete messages need to be  stored or only packets.\r\n\r\nLooking into msg 3 of our 7th scenario, I believe we made the wrond decision.\r\n\r\nMsg 3 has packet 41 and packet 15 for nominal direction.\r\n\r\nPacket 41 indicates the requested level transition to level 2.\r\nFirst problem: in the current implementation, the information level 2 transition pending comes from a later cycle back to the entry.\r\nProposed solution: packet 41 is evaluated as a part of the handling of the incoming message.\r\nOtherwise, the complete message has to be ignored.\r\n\r\nSecond problem: packet 41 has to be forwarded to level management, packet 15 (and others) have to be stored for after the level transition.\r\n\r\nWith this use-case, we have two potential reasons for the error: message flow is not correct or the element filter needs to be able to split this information in parts to store and parts to send.\r\n\r\nI will take care for a work-around \r\n@BaseliyosJacob : can you please analyse the use-case."},"comment":{"url":"https://api.github.com/repos/openETCS/modeling/issues/comments/129362576","html_url":"https://github.com/openETCS/modeling/issues/646#issuecomment-129362576","issue_url":"https://api.github.com/repos/openETCS/modeling/issues/646","id":129362576,"user":{"login":"JakobGartner","id":8400941,"avatar_url":"https://avatars.githubusercontent.com/u/8400941?v=3","gravatar_id":"","url":"https://api.github.com/users/JakobGartner","html_url":"https://github.com/JakobGartner","followers_url":"https://api.github.com/users/JakobGartner/followers","following_url":"https://api.github.com/users/JakobGartner/following{/other_user}","gists_url":"https://api.github.com/users/JakobGartner/gists{/gist_id}","starred_url":"https://api.github.com/users/JakobGartner/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JakobGartner/subscriptions","organizations_url":"https://api.github.com/users/JakobGartner/orgs","repos_url":"https://api.github.com/users/JakobGartner/repos","events_url":"https://api.github.com/users/JakobGartner/events{/privacy}","received_events_url":"https://api.github.com/users/JakobGartner/received_events","type":"User","site_admin":false},"created_at":"2015-08-10T08:28:23Z","updated_at":"2015-08-10T08:28:23Z","body":"I have analysed.\n\nThe track model does not send any information Q_DIR: “reverse”.\n\n- All packets sent for LRBG=354 are set to \"nominal\"\n- The message 3 sent from Build_RBC_LRBG_354_D_00275_3_M003 and from do not contain any Q_DIR field at all (as Message 3 does not have it at all)\n\nThe problem now arises here:\n\nMessage 3 is translated into Radio_Types_Pkg::Radio_TrackTrain_Header_T in the operator TM_RBC_conversions::M003_to_Radio_Track_Train_H where Q_DIR (as it is anyway invalid for this Message type) is set to an arbitrary value (which in this case is “reverse”.\n\nYet another example for this type definition being not very clean, and the need to replace it in the next iteration, as well as the need to have “information not valid” field on all enumerated types (which is also better for clean error handling).\nTrackMessages will get a lot of work to do...\n\n\nSo what do we do now?\n\nObviously it is wrong to rely on a data field (q_dir) for filtering which is nonexistent.\nNo part of the ReceiveTrackSide should read this. \nA M3 has no Q_DIR info at all (and I am sure that this kind of pseudo-overloading appears at more places)\n\n\nAs a quick workaround I can offer to change TM_RBC_conversions::M003_to_Radio_Track_Train_H so that it takes Q_DIR from a packet that comes with the Message 3, but this is a *DIRTY* solution.\n\nWe need to review the way messages are treated overall. \n\n\n\n\n\n\n\n\n\n> On 10 Aug 2015, at 09:40, Bernd Hekele <notifications@github.com> wrote:\n> \n> I have seen message 3 after balise 354 in reverse. Can you please check in the track-model whether this is to be corrected?\n> \n> —\n> Reply to this email directly or view it on GitHub <https://github.com/openETCS/modeling/issues/646#issuecomment-129338388>.\n> \n\n"}}