Issues about using DEN service under Veins

[ruisonghan]

Hi, Riebl

With the help of your work, I can build some simple scenarios of my own. Thanks so much.

However, when testing my scenario, I found that the DEN service and its use cases may not work when using Veins module as the PHY.

My scenario:
A truck controlled by Storyboard will stop and send a DEN messages, and vehicles receiving this message will stop or avoid the choosing the road where the truck is.

My work:
I added my DEN use cases under artery/src/artery/application/den/ and added my scenarios under artery/src/artery/scenarios.

The problem and relevant test:
Everything goes well when using the INET network as the PHY in omnetpp.ini, but when changing INET to Veins, my use case doesn't work anymore. Vehicles were not controlled by my use case.

In order to know why, I tested your TrafficJamAhead use case (one use case of DEN service) under the scenario storyboard. I added some outputs in void TrafficJamAhead::initialize(int stage) using EV commands. It looks like this:

void TrafficJamAhead::initialize(int stage)
{
    UseCase::initialize(stage);
    if (stage == 0) {
        mNonUrbanEnvironment = par("nonUrbanEnvironment").boolValue();
        mDenmMemory = mService->getMemory();
        mVelocitySampler.setDuration(par("sampleDuration"));
        mVelocitySampler.setInterval(par("sampleInterval"));
        mUpdateCounter = 0;
        mLocalDynamicMap = &mService->getFacilities().get_const<LocalDynamicMap>();
        EV << "***TrafficJamAhead::initialize stage=0***";
    }
    EV << "***TrafficJamAhead::initialize***";
}

The results:
When using INET, I could see these outputs in the log window of OMNet++.
While, on the other side, I could not see these output with Veins and it seems that TranfficJamAhead doesn't initialize at all.

My question:
I am not sure whether this occurs due to my own fault or not, since I have done some modifications to the DEN service. But since I can run my scenario correctly under INET, why it is not OK with Veins?

[riebl]

Sorry @ruisonghan, I cannot reproduce the problem you have described. I have set a breakpoint at TrafficJamAhead::initialize(int) and it is reached in both cases, the INET as well as the Veins variant, of the storyboard scenario.
Please note that we are primarily using INET so the support for Veins is a little bit sluggish and less tested. Can you verify that the useCases parameter of DenService is set correctly on your system?

[ruisonghan]

Sorry @ruisonghan, I cannot reproduce the problem you have described. I have set a breakpoint at TrafficJamAhead::initialize(int) and it is reached in both cases, the INET as well as the Veins variant, of the storyboard scenario.
Please note that we are primarily using INET so the support for Veins is a little bit sluggish and less tested. Can you verify that the useCases parameter of DenService is set correctly on your system?

I am checking all my codes and I will tell u the results when done.

But I don't think it is the problem of DenService since with INET, the TrafficJamAhead::initialize(int) works well. My artery was last updated in November and there were changes for Veins , Middleware and other modules after November. Now, I will check whether this could contribute to my problem.

[ruisonghan]

My first thought was whether my issue is related to #7, but codes have changed a lot. Anyway. I will check my codes.

[ruisonghan]

Sorry, I still don't know the reasons after checking my codes.

I added some output in Usecase.cc with the following command:

EV_INFO << "UseCase::initialize"<< endl;

I got the following logs, but it seems that TrafficJamAhead and Usecase were not initialized.

World.node[0].appl.middleware: Initializing module World.node[0].appl.middleware, stage 1
World.node[0].appl.middleware.CaService: Initializing module World.node[0].appl.middleware.CaService, stage 0
World.node[0].appl.middleware.DenService: Initializing module World.node[0].appl.middleware.DenService, stage 0
World.node[0].appl.middleware.DenService.TrafficJamEndOfQueue: Initializing module World.node[0].appl.middleware.DenService.TrafficJamEndOfQueue, stage 0
World.node[0].appl.middleware.DenService.TrafficJamAhead: Initializing module World.node[0].appl.middleware.DenService.TrafficJamAhead, stage 0
World.node[0].appl.middleware.DenService.ImpactReductionContainerExchange: Initializing module World.node[0].appl.middleware.DenService.ImpactReductionContainerExchange, stage 0

Do u need me to share the codes with u?

Thanks

[riebl]

Turned out that the CCH carrier frequency was not set correctly in the storyboard scenario's configuration using Veins PHY/MAC.
I have fixed this in 50cf65b. Please try again :-)

[ruisonghan]

Turned out that the CCH carrier frequency was not set correctly in the storyboard scenario's configuration using Veins PHY/MAC.
I have fixed this in 50cf65b. Please try again :-)

Hi, Riebl

Thanks, it works.

May I know why there is still no output of logging information in OMNeT++ if I add some log commands like EV into void TrafficJamAhead::initialize(int stage) under the Veins scenario?

[riebl]

EV equals EV_INFO: Maybe the logging level set in your OMNeT++ GUI suppresses info messages.

[ruisonghan]

EV equals EV_INFO: Maybe the logging level set in your OMNeT++ GUI suppresses info messages.

Hi, Riebl

I have read the simulation manual of OMNet++ and know that EV equals to EV_INFO.

I tried to set different levels of logging but failed to succeed. Info messages are just suppressed under Veins, instead of INET. Currently, I don't know what difference between Veins and INET made this happen.

[riebl]

I think this logging behaviour is more related to Veins than Artery. Since the original problem is solved I am closing this issue ticket. Do not hesitate to open another issue ticket if you think Artery is causing some problems related to logging.

[ruisonghan]

I think this logging behaviour is more related to Veins than Artery. Since the original problem is solved I am closing this issue ticket. Do not hesitate to open another issue ticket if you think Artery is causing some problems related to logging.

OK. Thanks again for solving the original problem for me.