taskCERTI - Tasks: task #10290, Implement [part of] IEEE-1516 API


You are not allowed to post comments on this tracker with your current authentication level.

task #10290: Implement [part of] IEEE-1516 API

Submitter:  Eric NOULARD <erk>
Submitted:  Mon 22 Mar 2010 08:13:42 AM UTC
Should Start On:  Sun 21 Mar 2010 11:00:00 PM UTC Should be Finished on:  Sun 21 Mar 2010 11:00:00 PM UTC
Category:  IEEE-1516 compliance Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  vyperx Percent Complete:  100%
Open/Closed:  Closed Planned Release:  CERTI 3.4.0
RTI Service Groups:  None

Jump to the original submission

Thu 11 Nov 2010 11:17:24 AM UTC, comment #22: 

This work has been integrated into CERTI 3.4.0.

Eric NOULARD <erk>
Group administrator
Mon 31 May 2010 09:38:14 AM UTC, comment #21: 

I've just checked-in the latest attached patch.
this one does neither includes the STATIC lib trick
nor the LogicalTimeDouble class.

Some remarks concerning modifications I did include myself before check-in:

- try to avoid mixin C style include and [new] C++ style ones.
  #include <math.h>
  should be
  #include <cmath>

- size_t is usually unsigned so beware of
  comparing "int" with "size_t".
  Most of the time you'd better use <cstdint> types
  uint8/16/32/64 and int8/16/32/64
  I did add the appropriate definitions in

- you may use STL algorithm std::for_each
  for deleting all point stored in a container.


  template <class T>
  struct deletor {
     void operator() (T* e) {delete e;};

  then use:
  struct deletor<whatevertype>  deletorWhatever
  std::vector<whatevertype*> c;

(file #20661)

Eric NOULARD <erk>
Group administrator
Sat 29 May 2010 09:27:30 PM UTC, comment #20: 

Update Jeroen Modif as a patch (with modifications)
Currently the patch does not compile on Linux,
there is some more work to do.

(file #20652)

Eric NOULARD <erk>
Group administrator
Thu 27 May 2010 12:23:36 PM UTC, comment #19: 

Hi Jeroen,

Thank you for all the updates.
I'll try to process them today
and will keep you informed of what is merged and what is not.

Concerning the test modules,
I'll put them in HLA_TestsSuite myself.

I'll have a tight look at the static lib solution.

Alternate logical time may be useful, we'll see
if we should keep such thing in CERTI
(built-on FedTime lib or as a separate lib)
and/or propose a separate module (like python binding etc...)

Eric NOULARD <erk>
Group administrator
Thu 27 May 2010 11:54:42 AM UTC, comment #18: 

Hi Eric,

I've added a new version of our CERTI-branch... I'm afraid we haven't merged any changes you may have made in the mean time, but I hope the overlap will not be that large. The test modules are also still under the CERTI project, so you may want to keep those out when merging.

Additionally, I have attached the overview of the implemented services. Please note that some services are not tested, although this is not indicated in the overview yet.

Also, I have added another LogicalTime implementation to the FedTime1516 library. This is the one that is used in our project (BITS), and was difficult to include for us otherwise. Things like that I think we should better keep as a user-patch to the main CERTI stuff, but it's there now.

Finally, I think I have solved the circular dependency problem by introducing a new static libary (ExportRTI1516), which contains the classes (Exceptions, etc) needed by the FedTime1516 dynamic library.

Kind regards,


(file #20635, file #20636)

Jeroen van IJperen <vyperx>
Group Member
Tue 25 May 2010 01:48:15 PM UTC, comment #17: 

Hello Eric,

Things are going quite well on this side. We've completed the RTI1516 services we require and are now moving our original project to make use of CERTI.

We've partially tested the services we've ported, but we won't be testing all of them, because of budget constraints.

I'll fill in the spreadsheet tomorrow, along with a new version of the RTI1516 modules.

During the port of our project, I'm sure we will find some additional stuff in Certi that needs porting/fixing, so we're not completely done yet. :)

After this I'm not sure yet how things will go for me personally (with regard to new projects), but if I have the time, I'll put in some work to 'round off' the work we did for CERTI. (I.e. better responses for the test cases, using correct .cc/.hh files, etc.)

Jeroen van IJperen <vyperx>
Group Member
Tue 25 May 2010 01:38:18 PM UTC, comment #16: 

Hi Jeroen,

Maxime is currently working on test case based on
Pierre interactive federate (in HLA_TestsSuite).

The idea is to use the interactive federate which is kind
of "scriptable" federate which makes it possible to test
different services. (In the same spirit of your unit test).

I'll ask him to give all of us an
update during this week and/or at the beginning of next week.

Last message from Maxime (with the spreadsheet attached)
was a proposition to share the effort from missing services.

If you tell us where you are in the IEE-1516 service implementation (done or on-going) we can jump to implement
the un-started ones on our side.

Do you have any updated patch?
Is it going well on your side?

Eric NOULARD <erk>
Group administrator
Tue 04 May 2010 12:22:29 PM UTC, comment #15: 

I have attached table with all IEEE 1516 services.
The goal is to know which service is already implemented and what remains to do.

(file #20423)

BAUDRAIS <mbaudrai>
Thu 29 Apr 2010 09:20:20 PM UTC, comment #14: 

2) Compiling CERTI with cygwin hasn't been done since a while
may be you could try with mingw32 + nmake
or even Code::Blocks (http://www.codeblocks.org/) for which
there is a CMake generator target on Windows.
Code::Blocks is shipped with gcc.

for the generic building

4) OK. And yes good idea to put a separate zip containing
   the tests. I may try to put them myself in HLA_TestsSuites.

6) Fine thank you, we'll try to handle/merge those bug fixes
   faster for all.

Eric NOULARD <erk>
Group administrator
Thu 29 Apr 2010 08:19:59 AM UTC, comment #13: 

Hello Eric,

Thanks for the feedback.
1) __declspec on Win32 only - I'll keep it in mind. I think we skipped it at first because we were trying to get it to work.

2) throw declarations should match - Good call on that. Unfortunatly VS doesn't warn us about that. I'll see if I can easily get GCC to compile it under Cygwin. At least for the warnings...

3) Add messagetypes/enums at end - I can see how that's required for backwards compatibility. I'll do that from now on.

4) Move tests to HLA_TestSuite - For now I think I'll keep them in the 'certi' part. If I'd move them to the 'applications/HLA_TestSuite' they would end up in a different VS solution, meaning I would have to open two VS instances... Near the end of development I will definetly move them there.

5) Commit HLA1516 to CVS - Thanks! I hope people have a chance to experiment a bit with it... Perhaps I can add the RTI1516Test as a seperate Zip here so people can take a look at the tests.

6) fixed bugs Interaction publish/subscribe - Yeah, it would have been better to report that as a bug, with a patch for a fix. I have just uploaded a patch for another bug I found... (waitForMessage deadlock on exception). I'll keep doing that for any bugs I may find.

7) Warnings on handles - It seems the derived handles override the base 'operator=' operator. I actually think the base does not need the 'operator='... I'll take a look into it.

8) Double macro definition in RTI1516fedtime.h - I added that part because the VS 'IntelliSense' kept insisting it was defined as import, while it should export. Removing the macro still allowes it to compile, so I'll remove it.

The merge went fine, so we'll continue development today. :)

Jeroen van IJperen <vyperx>
Group Member
Wed 28 Apr 2010 06:56:10 PM UTC, comment #12: 

Hi Jeroen,

That's good work, I did partially checkin
your work in the CVS HEAD tree.

Here comes my more detailed remarks.

1) Beware of the fact that
__declspec(dllexport) / __declspec(dllimport)
are only used on windows so the definition
of the corresponding macro should be defaulted
to empty on other platform.

win32 specific part of code should be surrounded
#if defined(_WIN32)

2) Beware of the fact that header (.h/.hh)
   and body (.c/.cc) should have the very same prototype
   including eventual "throw()". I did fix a couple
   of those.

3) When adding and/or modifying message classes   
   and thus modifying the message specification files
   CERTI_Message.msg for M_Classes
   CERTI_NetworkMessage.msg for NM_Classes
   try to add your messages at the end of the file
   (but before the native types and the factory)

   In the same way, please add the concerned
   enum values at the end of Message.hh::enum Type
   and NetworkMessage.hh::enum Type

   This way you'll avoid to make old enum values move
   In fact this is not currently "mandatory" but it will
   soon be if we want to try to maintain compatibility between
   CERTI versions.

   So please put new messages at the end unless you have to
   do it otherwise.

4) Concerning the RTI1516tests your initiative is very good
   and I invite you to continue along this path.

   However I'd rather put those tests inside HLA_TestSuites
   source module and not in CERTI source module.
   The main idea here is that those test may well be RTI-agnostic
   (they are just HLA federates)
   and building such open source RTI independent test suite
   would be nice.

   Moreover there is inside HLA_TestSuites some python helper
   scripts which makes it possible to run the whole test suite
   with a single make test
   (for each test RTIG is killed/launched appropriately and
    the federates (1 or more) launched too, then the output
    ot the test is monitored for OK <-> NOK etc...)
   More on this later.

5) After some Linux compile fix I did run usual and current CERTI HLA 1.3
   regression tests suite (HLA_TestsSuite, HLA_Tutorial and billard)
   since they are OK,
   I did commit your change with needed fix for a Linux
   This way it would be easier for other
   including Maxime to follow (and participate) to the work.

   However I did not checked-in the RTI1516tests.

6) I've seen you have fixed bugs concerning
   publish/subscribe to interaction in RTIG_Processing.cc
   this is fine off course. But when you do that please
   try to file a separate bug report and a separate
   patch. This makes it easier to track bug and associated bug fixes.  

7) There remains weird compile warnings like:
   /home/eric/workspace/certi-integration/libRTI/RTI1516HandleImplementation.h:41: warning: ‘virtual rti1516::HandleImplementation& rti1516::HandleImplementation::operator=(const rti1516::HandleImplementation&)’ was hidden
/home/eric/workspace/certi-integration/libRTI/RTI1516HandleImplementation.h:103: warning:   by ‘rti1516::FederateHandleImplementation& rti1516::FederateHandleImplementation::operator=(const rti1516::FederateHandleImplementation&)’

  and I did add a // FIXME Eric-->Jeroen in RTI1516fedtime.h
  but we will fix those gradually. I'd rather check-in gradually
  in order to ease testings and patch proposal from others.

I invite you to update (carefully as usual in order not to loose
local modifications) and retry a WIN32 compilation (I did not tried myself).

Again that's good work.

Eric NOULARD <erk>
Group administrator
Wed 28 Apr 2010 05:09:55 PM UTC, comment #11: 

Ok thanks,

Currently testing on Linux.

Eric NOULARD <erk>
Group administrator
Wed 28 Apr 2010 12:42:27 PM UTC, comment #10: 

I've attached a new version of the HLA1516 development... Actually, some test are now broken, but I guess that shows that we're still working on it. :)

We've only done compilation under Visual Studio (2005 & 2008), so please let us know if things aren't working under Linux (and how we can fix them :) )

(file #20358)

Jeroen van IJperen <vyperx>
Group Member
Tue 27 Apr 2010 07:35:23 AM UTC, comment #9: 

Hello Eric,

Glad to see you're back. :)
I will commit a new version for you tomorrow.

So far, things are progressing quite well, with a lot of the services ported directly to HLA1516...

I've also been working on a unit test system, which already identified some issues in the RTIA/RTIG code... So far, the unit tests still require manual handling, but I'm certain it could be adapted to be automatic, making it more useful in general.

Jeroen van IJperen <vyperx>
Group Member
Tue 27 Apr 2010 07:28:38 AM UTC, comment #8: 

Hi Jeroen,

I'm back now :-)
May be you have an updated contribution I may try to

I've fast-tried HLA1516-2010-04-13.zip on Linux and got some
compile error, however I'd better do the work on up-to-date
contrib from you in order to minimize the merge
on your side after my first commit.

Eric NOULARD <erk>
Group administrator
Thu 15 Apr 2010 01:19:23 PM UTC, comment #7: 

Thanks for keeping us informed, Eric. :)

Things are going quite well here. Services are being implemented, and I have started working on some unit tests. So far only found bugs in the rtia/rtig, so I guess that's good. :)

Enjoy your trip, and we'll see where we stand in a week.

Jeroen van IJperen <vyperx>
Group Member
Thu 15 Apr 2010 07:12:19 AM UTC, comment #6: 

Hi Jeroen,

I won't be very responsive for 7/8 days because I'm travelling
 and I do not always have efficient net access.
May be Pierre will get in touch with you and or I will
for sure when I'm back online.

Eric NOULARD <erk>
Group administrator
Mon 12 Apr 2010 11:17:43 AM UTC, comment #5: 

Hi Eric,

I'd be happy to have some (more) help. :) Let me know if/when he needs any info.

I've uploaded a new patch of my work so far. Unfortunatly I have had to make a 'branch' of some of the HLA1516 header files, in order to get the project compiling under Visual Studio. I've renamed them with a 'certi' prefix, and added an explanation in the file. Still trying to figure out a better way to solve this though.

Right now I'll start working on CERTI being able to parse HLA1516 FOM files. My collegue in the mean time will work on implementing the rti1516::handles and porting the various services.

Jeroen van IJperen <vyperx>
Group Member
Wed 07 Apr 2010 12:53:03 PM UTC, comment #4: 

Hi Jeroen,

We (Pierre and myself)
now have a student here which will help in this task too.
He will be working on Linux such that you may be reliefed
from this task.

He is currently beginning to learn HLA with CERTI
and then will coordinate with you in order to
do appriate complementary work.

Eric NOULARD <erk>
Group administrator
Mon 22 Mar 2010 04:57:00 PM UTC, comment #3: 

Hi Jeroen,

Here is a first feedback on your work.

1) I think you don't have to modify
   Unless I'm wrong
   the appropriate include for 1516 is: include/RTI/RTI1516.h
   and you should probably make CERTI specific
   modifications inside

2) I don't think we need separate RTIA for 1.3 and 1516
   the same RTIA should be able to handle both because
   RTIA is only processing internal CERTI messages.

   There may be 1516/1.3 specific messages but I think
   we should try to keep RTIA unique. It will be far easier
   to maintain.

3) libRTI1516
   Following the same idea I'll put 1516 and 1.3 files in the
   same libRTI directory.

   In fact you can modify the existing libRTI/CMakeLists.txt
   in order to compile libRTI1516 using same
   files as 1.3 (if they can be kept common 1516 - 1.3) or
   a separate new file (as you already did).
   i.e there may be

   and then


    I think you get the idea.

4) Please keep the same naming convention for file extension

     C++ header  = .hh
     C++ body    = .cc
5) I did merge-in your modifications of certi.hh


Eric NOULARD <erk>
Group administrator
Mon 22 Mar 2010 09:26:58 AM UTC, comment #2: 

I needed your Savannah account :-)
Now I have it so it's done.

As said on the ML, please attach some patches here
in order to ease the incremental integration of your work.

Thank you for contributing to CERTI

Eric NOULARD <erk>
Group administrator
Mon 22 Mar 2010 09:09:24 AM UTC, comment #1: 

Hi Eric,

As indicated on the mailing list, I have taken up this task. Can you assign it to me here? Thanks.

Kind regards,

Jeroen v. IJperen (vyperx)

Jeroen van IJperen <vyperx>
Group Member
Mon 22 Mar 2010 08:13:42 AM UTC, original submission:  

Many people want to use 1516 API instead of 1.3.
What we can do is to at least implement the same
services we have in 1.3 in 1516.

May be more than taht afterwards...

Eric NOULARD <erk>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #20661:  task10290-erk-jeroen4-1516only.patch added by erk (56KiB - text/x-diff - Latest patch including 1516 only modif (this one has been checked-in CVS HEAD))
file #20654:  task10290-erk-jeroen4.patch added by erk (86KiB - text/x-diff - Updated patch since previous one includes a separate bug fix now checked-in)
file #20652:  task10290-erk-jeroen3.patch added by erk (87KiB - text/x-diff)
file #20635:  tab2.ods added by vyperx (17KiB - application/vnd.oasis.opendocument.spreadsheet)
file #20636:  HLA1516-2010-05-27.zip added by vyperx (247KiB - application/octet-stream)
file #20423:  tab implementation.ods added by mbaudrai (18KiB - application/vnd.oasis.opendocument.spreadsheet)
file #20358:  HLA1516-2010-04-28.zip added by vyperx (181KiB - application/octet-stream)
file #20203:  HLA1516-2010-04-13.zip added by vyperx (72KiB - application/octet-stream - Updated patch. Waiting for my collegue before replacing extensions.)
file #20003:  HLA1516-2010-03-22.zip added by vyperx (127KiB - application/octet-stream - Patch/content so far. Approach is to copy existing RTI(A) and replace with 1516 functionality.)


Depends on the following items: None found

   bug dependencies.


Carbon-Copy List
  • -email is unavailable- added by mbaudrai (Updated the item)
  • -email is unavailable- added by erk (Will help on this task too)
  • -email is unavailable- added by erk (Pour suivre l'implem' de la 1516)
  • -email is unavailable- added by vyperx (Posted a comment)
  • -email is unavailable- added by erk (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    Follow 20 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-11-11 erk StatusIn Progress Done
        Percent Complete70% 100%
        Open/ClosedOpen Closed
        Planned ReleaseUnplannedRelease CERTI 3.4.0
    2010-05-31 erk Dependencies- bugs #30003 is dependent
    2010-05-31 erk Attached File- Added task10290-erk-jeroen4-1516only.patch, #20661
        Percent Complete60% 70%
    2010-05-30 erk Attached File- Added task10290-erk-jeroen4.patch, #20654
    2010-05-29 erk Attached File- Added task10290-erk-jeroen3.patch, #20652
    2010-05-27 erk Percent Complete0% 60%
    2010-05-27 vyperx Attached File- Added tab2.ods, #20635
        Attached File- Added HLA1516-2010-05-27.zip, #20636
    2010-05-04 mbaudrai Attached File- Added tab implementation.ods, #20423
    2010-04-28 vyperx Attached File- Added HLA1516-2010-04-28.zip, #20358
    2010-04-12 vyperx Attached File- Added HLA1516-2010-04-13.zip, #20203
    2010-04-07 erk Carbon-Copy- Added mbaudrai
    2010-03-22 vyperx Attached File- Added HLA1516-2010-03-22.zip, #20003
    2010-03-22 erk StatusNone In Progress
        Assigned toNone vyperx
        Carbon-Copy- Added siron

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code