It is All about Traffic, and Programming
Search
Archives
0 visitors online now
0 guests, 0 members

W.X.

Dissecting Vissim COM Internal from Inside Out (4) – a “Loophole” for a Perfect Solution

Previously I have a series of articles on “Dissect Vissim COM Internal from Inside Out”. You are welcome to re-visit them:

You are also welcome to re-visit another previous article of mine, which provides somewhat in-depth coverage of Vissim COM Instance Model.

  • Those articles are pretty technical but provide quite a bit of insights on how Vissim COM is designed and how it works. They were originally motivated by the single question: How to access Vissim COM interface data during run-time from inside a DLL, e.g., External Driver Model DLL, or Signal Control API DLL?

In these articles, various techniques were discussed to address the above question. However, these techniques require deep knowledge of Assembly language, Microsoft Component Object Model, and other techniques that may not be practical for ordinary Vissim users.

Today, let me introduce an easy and effective approach, of accessing ANY Vissim COM interface data from any Vissim-loaded DLLs (such as External Driver Model DLL, Signal Control API DLL or Emission Model DLL etc).

This approach is based on a “loophole” of Vissim’s COM interface design; the “loophole”, as we call it, may not be originally planned/intended as a common use case of Vissim COM applications, and yet it is a workable trick that we can utilize to our “convenience”.

To accomplish what just said, we need to use Vissim Event-based COM script. As you may have already known, Vissim Event-based COM scripting is a handy feature that allows you to write scripts in VB, Python and JavaScript.

Oh… Wait, as a matter of fact that may surprise you – it does allow you to write scripts in ANY language registered as the Active Scripting Engine on the Windows Script Host that comes with the Windows Operating System.

In short, Vissim Event-based COM scripting is really based on the Active Scripting technology. An end user can access Vissim’s interval COM interface objects via a hosted scripting engine such as Python or JavaScript. Any script running by Vissim is sharing the SAME memory space as the Vissim host.

And from inside the script, you have access to almost all of Vissim COM interface objects properties and data. You can also invoke any COM object’s interface methods – Vissim COM objects implement IDispatch interface so the script can invoke the methods by their symbolic names (rather than by their direct memory address, hence, slow).

The above facts render a new approach to pass any Vissim COM interface data to a DLL, such as Vissim External Drive Model DLL, or Signal Control API DLL. Until this point, you will probably have recognized immediately that this opens a whole new world of opportunities for really powerful and cool applications.

OK. Enough talk. The following are illustrative steps that have been tested, and just works!

STEP 1: Write the following Python script – as you can see, it is named as “ComDataExport.py”.

STEP 2: Export a new function from External Driver Model DLL “CallFromComScript”.

STEP 3: Add the script to Vissim simulation model as below

STEP 4: Assign the External Driver Model DLL to a vehicle type. And that is it. You can send ANY COM interface data to the Driver DLL!

Now that you have read to this point, you will see that this essentially creates a “tunnel” between Vissim COM interface and the target DLL. In this case, the target DLL is the External Driver Model DLL, but it could something else with your imagination and creativity.

The beautiful thing is, because the script is “event based”, i.e., it is invoked by “event” such as “beginning of simulation step”, you can actually have very fine-grained control of this data pass-through process.

I am excited. Are you?

One caveat: we can only use this approach to pass Vissim COM interface data (property value). You won’t be able to pass through references (memory addresses) of COM interface methods (because the COM interfaces in the script namespace are really …. “marshaled” active scripting items, not real objects)

Why, is this a “loop hole”? You may ask with a smile, finally. Well …… it is called a “loophole”, in the sense it is not part of the “original” design. It also provides an extra mechanism for “DLL Injection” beyond the scope of this article.

OK. That is good enough. Be Creative, and have fun.

Who touches my “for-loop” condition?

A for loop is a common control structure that allows repetitions of certain statements for a specific number of times. The syntax of a for-loop in C++ or C# is

for (initialization; condition; increment) {
   statement(s);
}

As simple as ABC. As easy as a no-brainer. As happy as Clam.

Now, look at the following C++ code. How many times would the the loop execute?

int main( )
{
   int N = 10;

   for ( int i = 0; i < N; i++ ) {
     N--;
     std::cout << "i = " << i 
               << ";"
               << "N= "  << N 
               << std::endl;
   }

   return 0;
} 

As the output shown below – The loop executes 5 times, even though we set N = 10.  Obviously, modifying N inside the loop body, i.e., N–, causes the termination of the loop prematurely.

Generally speaking, it is a bad practice to modify loop termination condition inside a for-loop. Bad, Bad, Bad!

Now, the same question for a similar Delphi code:

uses
  System.SysUtils;

var
  I, N: Integer;

begin
  try
    N := 10;

    for I := 0 to N do
    begin
      Dec(N);
      WriteLn( Format('I=%d, N=%d',[I, N]) );
    end;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

The output is not so much unsurprising – unlike the C++ counterpart, it does loop 11 times:

Interesting. It seems modifying N inside loop body doesn’t impact the number of intended loop execution times.

Let’s check the disassembled C++ binary:

As seen from the highlighted lines, N is referenced by address (i.e., ptr [N]) in loop body. This means, any change to N’s value will eventually impact the termination condition evaluation. Address [ebp-14h] is the local variable i stored in Stack, which is incremented with every repetition of the loop, before comparing to ptr[N] that is decremented with each loop.

Delphi compiler generates something different:

N is addressed at [0x004258a8]. At the beginning of the loop, N’s value is copied to [$ebp-$14]. Each loop just checks [$ebp-$14] for termination. Modifying the original Nwouldn’t impact the loop termination condition evaluation.

So, though it is generally not a good practice to change for-loop termination condition inside the loop,  Delphi obviously has some compiler caveat that may slip the mind of a careless programmer. Be warned!

Lane Closure Utility Updated for VISSIM 9

Lane Closure Utility was initially developed in 2006 as an amateur/hobby work by a then graduate student.  Surprisingly,  it had been found useful,  and has been used by quite a few industry engineers, graduate students,  and academic researchers in their work.  I would like to thank them again for giving me feedback and inputs.

I just updated this free little utility to work with VISSIM latest 9.x version.

PTV made a LOT, really a LOT of changes to VISSIM COM interfaces – which is annoying but understandable given their grand plan of overhauling and refactoring the system’s application framework inside out –  that however made this upgrade quite eventful trying back and forth to figure out a lot of undocumented changes. Anyway,  I managed to just upgrade the code to match the latest VISSIM version COM interfaces.

It can be downloaded here: vissim9-dist-x86-x64  Feel free to download and distribute.

For those interested – my previous post about this little utility is here, so you can learn how to use it (easy and simple!)  Another big surprise to me as I found today is that – the original post has been read for almost 5000 times!  Wow.  I would be even happier  if you’d left me some comments,  good or bad.

Lane Closure Utility for VISSIM 5.40 (32bit and 64bit)

 

Midtown In Motion Covers More Intersections and Wins National Innovation Award

New York City Department of Transportation today announced the expansion of Midtown in Motion, the innovative congestion management system deployed in Manhattan since last year.

The first phase of Midtown in Motion has resulted in an overall 10% speeds improvement as suggested by the E-ZPass travel time data and taxi GPS data.   The initial deployment for real time congestion control included 100 microwave sensors, 32 traffic video cameras and E-ZPass readers at 23 intersections to measure in real time traffic speeds,  travel times,  traffic counts and occupancies.

This new expansion of Midtown in Motion will have  a total of 210 microwave sensors, 56 traffic cameras and E-ZPass readers at 59 intersections, covering the Midtown Manhattan area from 1st to 9th avenue and from 42nd to 57th street,  more than 270 square blocks  (more than 300 controlled intersections) .  The collected real time data are fed to sophisticated algorithms and signals are updated accordingly (operator-in-loop or autonomously).

Midtown In Motion has won ITS America Smart Solution Spotlight Award , in recognition of New York City’s commitment to “smart” technologies that allow engineers to respond to traffic conditions in real time.

 “From cameras to microwave sensors and EZ-pass readers to Advanced Solid State Traffic Controllers, Midtown in Motion is a showcase of the most sophisticated intelligent transportation solutions available to public agencies. ITS America is excited to recognize this comprehensive use of technology and real time data which has resulted in a highly successful deployment that can be replicated in cities throughout the country.”  – Scott Belcher, President and CEO of ITS America.

Details of the Press Release are available at the NYCDOT website and the ITS America website

http://www.nyc.gov/html/dot/html/pr2012/pr12_25.shtml

http://itsa.org/component/content/article/1-general/1431-nycs-midtown-in-motion-receives-national-transportation-award