WuPiN G XiN BloG

It is All about Traffic, and Programming



0 visitors online now
0 guests, 0 members

Brain-Wave Controlled Traffic Simulation: Control a Vissim Simulated Car (2)–Open Box

Emotiv  EPOC Neuroheadset  (Special LImited Edition) is priced a little over $400, and shipped in a nice box.  The package includes the headset, a sensor box with 16 sensors, a USB wireless receiver, and a charger. If you are willing to pay a little more, you can get an enhanced edition with firmware providing the raw EEG data. But I chose not to.


The following picture shows the package box.  The design is nice and the model in the picture looks cool.



As you can see, the headset is sleek and looks with some Sci-Fi taste.  Can you see the he sensor sockets?


This picture shows how it looks after all the sensor pads are put into the sockets.  They have to be soaked with the supplied saline liquid.



This picture shows the SDK control panel. The diagram shows the sensor signals.


The picture below shows the real-time charts of my brain activities, the Y axis represents the intensity of the signal. Different color of charts represents different emotions such as frustration, excitement, meditation etc.



Clearly, the EEG data of my brain activities suggest I am amidst  potpourri emotions including frustration, excitement, boredom and others. Gee, I think I love this little Gadget.


(to be continued).

Brain-Wave Controlled Traffic Simulation: Control a Vissim Simulated Car (1)

Ever watched the movie “Carrie”, a classic produced in 1976 from Stephen King’s 1974’s horror novel?  An abused 17-year-old girl with telekinesis, gets pushed to the limit by a humiliating prank,  and finally took her revenge with her power – turning her school’s prom into a bloody night of killing.

You might want to develop telekinesis on your own,  so as to get back on whoever you get pissed of with – Good Luck on That!  Here is a nice tip on How to Develop Telekinesisjust let me know how it works!!

What we are going to talk about today is the so-called Brain-Computer-Interface (BCI), which is about using your brain wave patterns to train a computer program, while the latter directs some device doing some nice, dirty, and/or even horny (you wish!)  jobs for you   😆  

Here is an excerpt from Wikipedia:

A brain–computer interface (BCI), sometimes called a mind-machine interface (MMI), or sometimes called a direct neural interface (DNI), synthetic telepathy interface (STI) or a brain–machine interface (BMI), is a direct communication pathway between the brain and an external device. BCIs are often directed at assisting, augmenting, or repairing human cognitive or sensory-motor functions.

BCI uses Electroencephalography(EEG), which detects voltage fluctuations resulting from ionic current flows within neurons of brain. Whenever your neurons fire,  weak electrical signals in millisecond-range resolution propagates all the way to the scalp.This signal is at higher resolution than CT or MRI.

Therefore, BCI is pretty much about signal processing, machine learning and pattern recolonization recognition.

EEG was invented in early 1900’s, hence it is not something new.  However, when the time comes to 2010’s,  the industry has come out with cost-effective and portable EEG devices (unlike those used in medical applications).  Novel applications are thus enabled.  The following pictures (source:http://emotiv.com/) illustrate a conventional EEG and a portable EEG device.

compare1 compare2

The following picture shows Emotiv EPOC EEG device, manufactured by Emotiv, featuring

16 wet electrodes, 14 EEG electrodes read brain waves, two-axis gyroscope to read head movements, 4 mental states, 13 conscious thoughts or facial expressions, 4 processing suites

The wonderful thing is, this little device sells for only $399 desktop or $499 for Bluetooth Smart, with full programming SDKs. You can even integrate it with wearable devices (such as Google Glass).


And, that is what I am gonna do.  I am going to use this little gadget, and its SDKs to interface with VISSIM microscopic traffic simulator via its COM interface and Driver API – so I can:

  • Command a simulated car to brake, accelerate and stop,  using my brain wave – termed otherwise,  by simply staring at my computer screen like a dork 😯 .

That is right.  I am going to present an interesting demo here that Brain-Computer-Interface for the first time,  being used in traffic simulation to control a simulated car…… (I really wish one day I could use the same to command my boss to pay me more  😈 )

Stay tuned. It is going to be realllllly FUN.

(to be continued)

Adaptive Signal Control for Diamond Interchanges

A new adaptive signal control deployment for a total of 15 intersections at freeway diamond interchanges go live yesterday Oct 10, 2014, in Staten Island of New York.

Diamond interchange is characterized by two closely spaced intersections, with left turns on the common approach connecting the two intersections. The common approach generally is a short block fed by movements from various phases.

Traffic signal control at diamond interchange can be viewed as a special type of over-saturated control with unique geometric features. The primary goal is to facilitate vehicle movements, while preventing queuing back to other approaches and ensuring pedestrian safety. Generally small cycles are preferred over long cycles.

Conventionally, adaptive traffic signal control primarily targets progression optimization or delay minimization in unsaturated conditions, with its insufficiency dealing with over-saturated traffic.

This system is powered by the ACDSS adaptive control technology developed by KLD, integrated with TransCore TransSuite TCS.  Thanks to its unique design of the so-called Signal Optimization Repository,  ACDSS is capable of  addressing the real time signal optimization for diamond Interchanges, urban CBD grid, arterials, and cluster of intersections.  It can be either running as cycle-based, or second-by-second (cycle-free).

The same system has been deployed controlling more 300 intersections in Manhattan of New York City, and being installed in other states including California as well.

Advanced Aimsun API Programming (2)

Aimsun MicroAPI has a total of 444 functions,  in three header files:

  • AKIProxie
  • ANGConProxie
  • CIProxie

These functions are ported to Delphi language, and the following shows a demo of obtaining vehicle information:

Aimsun API-Delphi Demo 1: Obtaining Vehicle Information

  • First the exported functions are defined in the project file, as follows:
// AIMSUN API  Delphi Interface
// Ported by Wuping Xin
// Last Update @2014-03-21 20:23:55

library AAPI_veh_info;

  AAPI in 'AAPI.pas',
  AAPI_Util in 'AAPI_Util.pas',
  AKIProxie in 'AKIProxie.pas',
  ANGConProxie in 'ANGConProxie.pas',
  CIProxie in 'CIProxie.pas';

{$R *.res}


  • Second,  the exported functions are actually implemented in unit AAPI.pas file, as follows:
unit AAPI;

  function AAPILoad: Integer; cdecl;
  function AAPIInit: Integer; cdecl;
  function AAPIManage(aTime: Double; aTimeSta: Double; aTimeTrans: Double;
      aSimStep: Double): Integer; cdecl;
  function AAPIPostManage(aTime: Double; aTimeSta: Double; aTimeTrans: Double;
      aSimStep: Double): Integer; cdecl;
  function AAPIFinish: Integer; cdecl;
  function AAPIUnLoad: Integer; cdecl;

  function AAPIEnterVehicle(aVehID: Integer; aSectionID: Integer): Integer; cdecl;
  function AAPIExitVehicle(aVehID: Integer; aSectionID: Integer): Integer; cdecl;
  function AAPIEnterVehicleSection(aVehID: Integer; aSectionID: Integer; aTime:
      Double): Integer; cdecl;
  function AAPIExitVehicleSection(aVehID: Integer; aSectionID: Integer; aTime:
      Double): Integer; cdecl;
  function AAPIInternalName: PAnsiChar; cdecl;

  function AAPIPreRouteChoiceCalculation(aTime: Double; aTimeSta: Double):
      Integer; cdecl;


  SysUtils, AKIProxie, ANGConProxie, CIProxie;

  function AAPIEnterVehicle(aVehID: Integer; aSectionID: Integer): Integer; cdecl;
    Result := 0;

  function AAPIEnterVehicleSection(aVehID: Integer; aSectionID: Integer; aTime:
      Double): Integer; cdecl;
    Result := 0;

  function AAPIExitVehicle(aVehID: Integer; aSectionID: Integer): Integer; cdecl;
    Result := 0;

  function AAPIExitVehicleSection(aVehID: Integer; aSectionID: Integer; aTime:
      Double): Integer; cdecl;
    Result := 0;

  function AAPIFinish: Integer; cdecl;
    Result := 0;

  function AAPIInit: Integer; cdecl;
    Result := 0;

  function AAPIInternalName: PAnsiChar; cdecl;
    Result := 'AAPI_veh_info';

  function AAPILoad: Integer; cdecl;
    Result := 0;

  function AAPIManage(aTime: Double; aTimeSta: Double; aTimeTrans: Double;
      aSimStep: Double): Integer; cdecl;
    lvVehInfo: InfVeh;
    lvNumOfSections, lvNumOfVehs, lvNumOfJunctions: Integer;
    lvSectionIdx, lvVehIdx, lvJunctionIdx: Integer;
    lvSectionID, lvJunctionID: Integer;
    lvVehInfoStr: string;
      lvNumOfSections := AKIInfNetNbSectionsANG;

      for lvSectionIdx := 0 to lvNumOfSections - 1 do
        lvSectionID := AKIInfNetGetSectionANGId(lvSectionIdx);
        lvNumOfVehs := AKIVehStateGetNbVehiclesSection(lvSectionID, True);

        for lvVehIdx := 0 to lvNumOfVehs - 1 do
          lvVehInfo := AKIVehStateGetVehicleInfSection(lvSectionID, lvVehIdx);
          lvVehInfoStr := Format('Vehicle %d, Section %d, Lane %d, CurrentPos %f, CurrentSpeed %f',


      lvNumOfJunctions := AKIInfNetNbJunctions;

      for lvJunctionIdx := 0 to lvNumOfJunctions - 1 do
        lvJunctionID := AKIInfNetGetJunctionId(lvJunctionIdx);
        lvNumOfVehs := AKIVehStateGetNbVehiclesJunction(lvJunctionID);

        for lvVehIdx := 0 to lvNumOfVehs - 1 do
          lvVehInfo := AKIVehStateGetVehicleInfJunction(lvJunctionID, lvVehIdx);
          lvVehInfoStr := Format('Vehicle %d, Node %d, From %d, To %f, CurrentPos %f, CurrentSpeed %f',



      Result := 0;

  function AAPIPostManage(aTime: Double; aTimeSta: Double; aTimeTrans: Double;
      aSimStep: Double): Integer; cdecl;
    Result := 0;

  function AAPIPreRouteChoiceCalculation(aTime: Double; aTimeSta: Double):
      Integer; cdecl;
    Result := 0;

  function AAPIUnLoad: Integer; cdecl;
    Result := 0;


 The above demo and the ported Aimsun API in Object Pascal can be downloaded from here.



Initial Setting up of Vissim COM in .NET environment

VISSIM’s kernel is pretty much written using  C++ (a lot of template programming),  including its COM part.  Its UI is written in .NET for a better user experience, though. The VISSIM COM API manual is mostly about using it with Visual Basic or VBA,  which has long been depreciated by Microsoft since Visual Studio 6.0.

For .NET environment,  no detailed description is provided as to how to import the COM lib.   Anyway, here are the list of the snapshots to show how to import Vissim type lib in .NET (VS 2012), to start VISSIM COM client programming.  It applies to all .NET languages, such as C# or VB.NET.

1. Create a new C# (or VB.NET project).


2. You will see something like below.


3. Right click “References”,  choose “Add Reference”..



4.  Choose “Browse”.


5. Browse to where Vissim is installed,  select “Vissim.exe” . Click “Add” , and click “OK”.


6. You will now see “VISSIMLIB” is added to the references list.  From this point on,  you can start referencing VISSIMLIB interfaces as in the C# example of the VISSIM manual.  Have fun.


VISSIM 6 SP11 Memory Leak – False Alarm

VISSIM 6.0 has some nice features as advertised by PTV sales – but the truth is it presents itself  with more headaches than convenience for its existing users.  To name a few – almost a complete re-design of new user interfaces,  frustrating performance (VERY slow execution even on a high-spec machine),  menu items of placeholders of functionalities not implemented yet ,  and so many other annoying glitches…

The latest Service Pack 11 was released a couple of days ago, and I noticed that it has a major memory leak issue (see below updated information abut this matter) – I am referring to VISSIM 32bit  on Windows 7 x64 OS (I didn’t check the 64bit version) – to replicate,  simply launch four instances, and close the instances one after another by either click the Close button on the upper right corner,  or from File->Exit.  No need to load network files.

NOTE: VISSIM only supports up to 4 concurrent instances.

Now, open the Task Manager, and you will see the 4 Vissim instances dangling there, forever, each consuming approximately 200 MB RAM, and 22 threads, and 131  GDI objects. To make it worse,

  • You will NOT be able to launch any new Vissim instances because of these 4 invisible dangling zombie Vissim instances.


  • You COM client applications will be screwed up as they will get confused when trying to connect Vissim instances and they will never succeed, causing the COM applications freezing out there.




**********************          UPDATE         ***************************

This “memory leak” turns out to having nothing to do with Vissim.  It is a ridiculous non-tech problem.

I was traveling in China, and I was using Vissim North American edition.  When the Vissim 6.0 software was launched and closed,  Vissim 6.0 will try to connect to some “foreign” servers that were probably on the “white list” of the Chinese ISP  (if you don’t know about China’s Golden Shield System, a.k.a known as Great Wall Firewall system and its DNS hijacking – please google).  That caused the very slow loading up, and never-end-closing of Vissim instances (sometimes, this doesn’t happen at all, but most of the time, it did)




Running VISSIM from within MATLAB

Vissim has a very nice COM-based programming interface – that a user can use any COM-compliant languages (as COM client)  to programmingly invoke Vissim (as out-of-proc COM server),  and performs some customized task.  Typically,  a user can use Excel/VBA, C#, Java,  Fortran, Delphi, C++ etc as his preferred language.

Matlab is a comprehensive computation platform with a lot of readily available numerical algorithms (e.g., Genetic Algorithms,  Support Vector Machine, Wavelet, Kalman Filtering etc.)  that can be very useful in simulation studies, research and development on customized and sophisticated simulation experiments.

Matlab provides very good support for COM – hence it is, in my opinion, probably the best Vissim COM programming environment if you have an academic minds and wish to do some cool prototypes and interesting simulation experiments.

  • For industry applications,  it is probably an overkill,  and the performance hit is a problem – Matlab essentially works the same way as Excel/VBA – this means all method invocations are “interpreted” – the stack frame is created by first querying a dictionary of method names to get the right function pointer,  amongst the mess of the inter-process marshaling.   C++, C# or any compiled language would be much faster as the stack frame is created directly from function pointer without the  querying step.  Wait – strictly speaking, C# is a bit different from other native language like C++, Delphi, or Fortran, as .NET/COM inter-op is via Common Language Runtime (CLR)’s P/Invoke which is another layer, rather than the pure native way.

Vissim User Manual doesn’t mention how to use Vissim COM wih Matlab.  It is not complicated but there is some catch to make it work, so I just put the procedures here – and,  if you find it helpful,  a loud “Thank You” would make me HAPPY!

First thing first,  in order to run Vissim COM,  you would need to know Vissim’s ProgID, which is a string-based name saved in Windows system registry, together with some other information (such as the path to Vissim.exe).  Here is an excerpt you need to read carefully from Vissim COM manual:

When working with Vissim  manually it is possible to start several instances of Vissim. You
can  also  start  several  different  versions  (e.g.  Vissim  5.40  and  Vissim  6.0).  The  same
applies  when  working  with  COM:  If  the  version  number  is  not  specified  (i.e.
CreateObject (“Vissim.Vissim”)),  the  Vissim  version  which  has  been  registered  as  COM
server most recently is started.  Specifying the version number during the call allows you to
start  a  specific  version  of  Vissim:  CreateObject (“Vissim.Vissim.540”)  for  Vissim  5.40  or
CreateObject (“Vissim.Vissim.600”)  for Vissim 6. If you have installed a 32-bit and  a  64-bit
edition,  you  can  use  “Vissim.Vissim-32.600”  or  “Vissim.Vissim-64.600”  to  start  a  specific
edition. A Vissim instance started via COM is automatically closed as soon all COM objects
are set to nothing.

This is kind of twisty, so let me rephrase it, with some simplifications:

  • If you only have one Vissim version installed, ProgID = “Vissim.Vissim”
  • If you have multiple Vissim version installed, ProgID = “Vissim.Vissim.XXX”, where XXX is the version number, e.g., 540 for version 5.40, or 600 for version 6.00. Please note,  service packs doesn’t count for version number, so service pack 1, 2, … n for the same version have the same ProgID
  • If you have multiple Vissim versions,  for 32bit and 64bit, then the ProgID = “Vissim.Vissim-YY.XXX”, where YY is 32, or 64, corresponding to 32bit or 64bit edition, XXX is the version number such as 540, or 600.

With ProgID in mind, and a Vissim COM interface online manual in front of you,  now you need to

  • Launch Matlab (in my example I am using Matlab 2013b), but I believe any Matlab version after 7.0 will do;
  • In the Matlab Command Window, type
    vissim = actxserver('Vissim.Vissim.600')

    Note here a ProgID string ‘Vissim.Vissim.600’,  with an explicit version number 600 is used. This is because on my computer I have two Vissim versions (540 and 600) installed. actxserver is a Matlab command that returns the default interface of the COM server, which in our case,  is IVissim interface.

  • Immediately you will see a Vissim 600 instance being launched automatically, and the main GUI shows up;
  • The Matlab variable, “vissim” is a handle to IVissim interface. From this point on,  you can use “vissim” to call various other interfaces, for example,
    vissim.LoadNet(‘whatever.inpx’), vissim.Simulation.RunContinuous, simulation = vissim.Simulation
  • You can do whatever you like now with Matlab,  including invoke  Genetic Algorithm routines or something else;
  • Finally, when you are done,  to destroy “vissim” (which is a reference-counted handle of IVissim interface),  simply put this line
    vissim = 0,  or alternatively,  vissim.Release

    then the vissim instance will be destroyed (to be more accurate  – released to decrement ref_count,  and destroyed if ref_count drops to zero) and the main GUI disappears from the screen.

Last, there are two little tricks working Vissim in Matlab environment , you can use .get to list all properties of an interface, and .methods to list all methods of an interface, for example:

You can immediately recognize that these are all listed in Vissim COM Manual – but it is good to verify by using .get  and .methods.



I found another good source of information on this subject is a white paper of Dr. Tamas Tettamanti, which provides a more detailed step-by-step document for Vissim-Matlab integration –



“Early-Return-to-Green”–What is the Big Deal?

Just returned from the Transportation Research Board (TRB) 93rd Annual Meeting , a.k.a TRB.  Meandering through the jungles of  papers, presentations and committee meetings — this has been my 8th attendance to TRB.

I felt I did have gleaned some gems, meeting some really smart people and humbled by some of the brightest brains.  Handshakes,  beers and a little catching up with old friends.  Ah!  Never before had I reflected so much on the profession that I have devoted myself to.


An interesting subject that I picked up from this TRB,  is an “issue” called “Early-Return-of-Green”, which is some sort of glitches coming out of Actuated Signal Control.   The following is an excerpt from FHWA website:


One of the consequences of coordinated, actuated control is the potential for the coordinated phase to begin earlier than expected. This “early return to green” occurs when the sum total of the time required by the non-coordinated phases is less than the sum total of the vehicle splits coded for the phases. While this may reduce delay at the first intersection, it may increase system delay because of inefficient flow at downstream intersections or, most important, the critical intersection of the network. Figure 6-26 illustrates this within a time-space diagram, that vehicles in coordinated phases that begin early may be forced to stop at one or more downstream intersections until they fall within the “band” for that direction of travel. This can result in multiple stops for vehicles and a perception of poor signal timing.


There are also quite a few papers and references in the past years discussing this,  some recent ones trying to revisit the “issue” using the so-called “high-resolution event-based signal data”.


To recap,  the “issue” is  nothing but that non-coordinated phases, with their actual green time being determined by vehicle actuations, may terminate early (gap-out)  without hitting the force-off points (which are defined by their splits).  The extra greens are then simply awarded to the coordinated phases.  As a result,  the coordinated phases start green earlier than the time that is defined by their splits.

This has been cited as a “BIG” problem that could damage arterial signal coordination in various publications.  Several serious methodologies, formulations and equations, or frameworks have been proposed trying to diagnose and “fix” the problem.


To tell you a little secret about myself – I am a die-hard big fan of the late Henry Barnes,  known for the “Barnes Dances”.  One of my favorite quotes of Mr. Henry Barnes was

“In this business there are very few problems that can’t be solved with some yellow paint and a little bit of common sense.”

Without resorting to pretty LaTeX-typesetted equations  (as an ego-satisfying proof that I am reeeeeally good at the so-called analytical thinking to interprété simple things in a complicated way,  if nothing else 😛 😉 😛 ) —  my “little bit of common sense” now begins churning and cries out loud:

What is the Bigggggg DEAL?

Not a big deal, at all – and here is my chain of logic as a quick-and-dirty Traffic Engineer:

First,  granted,  for a coordinated arterial the initial formation, and  coherence of the formed platoon,  with some of the intersections having this “early-return-to-green”,  might be temporarily impacted – however, the designed band is still there; it doesn’t disappear, isn’t missing or is taken away by aliens whatever, it is SIMPLY THERE.  This means, any vehicle arrivals within that band will still be able to clear the intersections without stopping.

Second,  as long as NOT ALL intersections have “early-return-to-green”,  there must be AT LEAST ONE intersection running according to the designed band,  where vehicles (that have arrived out of the extra-green time from the upstream intersections)  have to stop.  Contrary to someone’s belief that this is the “bad thing”,  my opinion is,  this is  GOOD instead,  as it provides THE  OPPORTUNITY for re-shaping the platoons. Stated otherwise,  the platoon might be impacted initially (see my first point), yet the platoon would be reorganized and reshaped sooner or later – the traffic system by nature is capable of self-organanizing itself,  isn’t that beautiful?

Third, even if all intersections have “early-return-to-green”,  so what?   Those vehicles being stopped due to the out-of-band arrivals would  have to be stopped anyway, regardless “early-return-to-green” occurs or not.   “Early-return-to-green” will not significantly increase stops or total delay — because it simply re-distributes the stops at various internal intersections.  Or, put it more precisely,  “early-return-of-green”,  though seemingly disrupts the designed progression,  will NOT significantly increase number of stops, nor increase the total delay as compared to the normal situation.  It will not make things any worse, if not making them better.

The “issue” is even more trivia, if the arterial has a high platoon ratio (i.e., the percentage of through traffic volume all  the way from the first intersection to the last),  while the boundary intersections have high minor street demand thus eliminating “early-return-to-green” at the boundary intersections – this essentially results in the platoon formed at the boundary, progressing through the designed green band regardless of whether other intersections in-between having “early-return-to-green” or not.

Last,  it is worth noting that, early-return-to-green might help increase the arterial capacity by helping shared turning vehicles,  largely due to the largess of extra green saved from minor phases.  And, that is the beauty of the actuated control.

Some papers proposed some methodologies, and showed that the new offsets proposed by the methodologies resulted in  less delays and number of stops.

Actually this proves nothing relevant to early-return-to-green, it only proves that previous offsets are not optimal.  In my opinion, to verify whether early-return-to-green really screws things up, we would need to check — for the same demand pattern and the same offsets and everything else controlled — whether delay and/or number of stops increase with early-return-to-green vs. no early-return-to-green (i.e., put max recall on minor streets so the minor phases are always forced out). My telling is, no, it will not screw progression as some of the papers have assumed. At least, it will not make things worse, if not better.

In my conclusion,  “early-return-to-green” is mostly not a bad thing for the designed arterial progression.  It even has some advantages that were not explicitly noted before.  The benefits of the “early-return-to-green” comes from the benefits of actuated control, while at the worst  the impact on the designed coordination pattern is probably just the unjustified driver perception of “bad” signal timing, and at best the extra green saved from minor streets help increase intersection capacities, especially when the arterial direction has heavy volumes already.   It might also help shared turning vehicles.

So for “early-return-to-green”, is there really something calling for a fix?

I guess it is not.  To me,  “early-return-to-green” is not a defect,  rather a welfare and benefit coming from actuated control.   Its impact on the arterial progression is probably not a serious “issue”  or a real problem,  albeit — it renders a good Don Quixotes‘ windmill for some type of exercises of the academic minds.

Agree? Disagree?


Updated on Jan 21, 2014 – admittedly this is a compounding and convoluted problem  –   especially if all possible shock wave paths and nuances considered.  But that is my point and there is a simple engineering solution to get rid of  (well,  largely to some extent) the complexities:

1.  Explicitly, do NOT allow early-return-to-green at the boundary intersection(s) ( plural,  if both directions are considered).  This makes sure that the primary platoons are formed and will be progressing in the band width, as designed.

2. Secondary platoons can surely take advantage of the “early green”, to get out of the way for the primary platoon. If the secondary platoons have to stop (in front of the primary platoon), so be it, they have to stop anyway because…because that is what they called – i.e., “secondary”…., even without those early greens. This is exactly why I say, “early-return-to-green” will not make things any worse, if not better.



P.E. Exam – Finally Done.

P.E. exam is less of technical of any sort than a legal token to practice engineering service in a domain. Technically,  it is nothing but the type of C-Level students’ exam – as long as you can get C-grades in undergrad courses,  you should have no problem passing it.

The “challenge”  comes from its covering many undergraduate subjects.  The breadth of the exam calls for a serious study. It is even harder if you’d left school for a while, and memory getting rusty.

I took the Oct 25 2013 P. E. exam yesterday – could have selected the subject of Civil Engineering with a focus on Traffic and Transportation.  The required part of Structure,  Water and Environmental was quite new to me.  In the end, I chose the Electrical Engineering subject with Computer Engineering as the specialized area.

PE exam is nothing but one of old-school-type of exams: they are  the simplest and easiest events of life. Why ?  Taking an “exam” – you are dealing with something for sure with standard answers  – whatever “standard” out there.  Real life is beyond an exam.  – NO “standard” answers,  or having at least 25% chances of getting it right simply by wild guess.

For the P.E. exam itself,  here are some of my suggestions/recommendations:

I would rate this manual as completely useless,  and a big waste of money. The book has granted a largess of 2/3 of its pages to the subjects of maths and Engineering Economics, which have nothing to do with the Exam.  Ridiculous the book is extremely sparing and reticent in giving only TWO pages to the important subjects such as Computer Architecture – which is expected to make up 35% of the Exam!

For Math,  I didn’t even bother to use any calculator during the exam.  All the numerical computation during the exam can be  carried out manually by hand or by brain, mostly binary.

These two little booklets turned out to be extremely helpful and you can count on them as the probe guides for preparing the exam.  As a matter of fact,  some problems actually showing up in the exam were quite similar (if not identical) to the samples  in the booklets.

Introduction to Computer Engineering: Hardware and Software Design. Taylor L. Booth. John Wiley & Sons

The Internet for Scientists and Engineers, Brian J. Tomas. SPIE Press.

If you dare to use these two books,  they would do you more BAD than GOOD.  Do yourself a favor getting away from them!

  • IEEE Guide to the Software Engineering Body of Knowledge (SWEBOK)

Fairly speaking,  the book is not bad – but it is not good either; useless for the exam.  No indices for fast key-word search.  The writing is too laconic to have any good information for the Exam.

  • The book I used for preparing for the exam, and found very helpful is:

Digital Design and Computer Architecture (2nd Ed) by David Money Harris and Sarah  L. Harris. This is an excellent, well-written, all-in-one book for the Exam. It covers a lot of the subjects in just one book.

  • Some chunky books that you don’t need to extensively study, but just remember to bring them to the exam site:

Modern Operating Systems (2nd Ed) by Andrew S. Tanenbaum – This book helped me with 2 or 3 Operating System problems in the actual Exam.

Software Engineering (9th Ed) by Ian Sommerville: This book helped me with 3 or 4 esoteric Software Engineering problems in the actual Exam.

The following general subjects showed up in the exam – particularly, pay attention to subjects such as Gray Code,  RAID,  Interrupt and DRAM timing diagram.

System Verilog, VHDL; Hamming Code, Parity check, checksum; Flip-flop, D-, J-K, S-R, Logic Arrays; CPU pipeline,  speed-up with multi-core,  real-time operating system scheduling algorithms, binary encoding, Unicode, Big-endian, Gray Code, interrupt (non-mask-able, mask-able), two’s complement;Floating point representation (exponent with mantissa), IEEE floating point exceptions; Shannon theorem, wireless communications (WDM/crosstalk), Network Protocols (TCP); CPU energy consumption, CMOS static and dynamic energy consumption; Arithmetic Shift, ALU, Instruction Set; Diode, operational amplifiers (very simple).

Bottom line,  Digital Design and Computer Architecture (2nd Ed) plus the two sample booklets would cover a large part of the exam subjects,  and the Software Engineering book by Sommerville and Operating System book by Tanenbaum can help with some unprepared problems in the actual Exam.  These books PLUS the two little booklets will help you pass the exam.

When studying, I didn’t invest much time on Electronics and it turns out that saved me a lot of time  – just basic understanding of the subject would be good enough (using the two booklets as guideline).