After IDR

After our initial design report (IDR) is finished, I can say that TRASTRAPS is nearly ready to be implemented. We gave many details about every part of our project. I believe that report is a sign of what we will do in project implementation.

This week, I did research about rule engines to implement to our project. However, I could not find any suitable rule engine for our project. All proper rule engines are for Java. However, we are using C++ in our project. We could use Java Native Interface in order to use java rule engines in our project but it decreases performance. Since performance is a concern for us, it is our job to implement a rule engine. I did a lot of research and tried to understand how rule engines work.

Here is a diagram that we are going to use in our Rule Engine design. This is forward chaining method for rule engines:



After I learned about rule engines, I tried to create some rules for our project. Here is some example rules that we are going to use in our project:

-If there are more number of allies then enemies then attack
-If there are more number of enemies then allies then run away
-If no ammo then run away.
-If being followed then run away
-If there is no enemy then continue mission.

That's all from me for this week.

-
Serkan Olgun

TRASTRAPS Database

After a long time, firstly I want to say something about our initial design report

As Ilke said, although there are some points that we keep them for the detailed design report, the initial one has already become a little book. Now, I want to mention about database design part of the initial design report. As our project is based on reusability of the scenarios, units assigned to them etc., database has a critical role in TRASTRAPS.

Four main entity types that will be stored in database are scenario, model, system and mission. Of course relationship between them will also be stored as I am going to explain in the following paragraphs.

Database design usually imitates the class hierarchy of the project entities. Actually, this is true for systems and models. There will be a main tables for system, model and mission entities that will be stored common properties of them. Differentiating properties of them are stored in different tables that contain tuples that are binded to main tables with their unique identifiers.

The relationships between those for main entities that will be stored are like in the followings:

- Scenario-unit
- Model-system
- Unit-mission

As an additional information, in TRASTRAPS terminology, units are instances of model.

The other entity type that we think to store will be rules. Storage and relationships of rules with other entities will be explained in detailed design report in more detail.

Suat

HLA - RTI Control

After writing the initial design report, we were completely exhausted. But we believe that we wrote an incredible report and it was just the beginning. We are still going on our research and finally started some coding.

Finally we decomposed our system into stand-alone modules and all are going to communicate through RTI. I googled some HLA and RTI sources that tell how those modules (each is in fact a federate) will communicate. For example, on Portico's web site there are useful examples written both
in C++ and JAVA.

In a federation, each federate is capable of sending and receiving objects that are defined in a FED (Federation Execution Details) file. This could be achieved by using functions such as publish and subscribe. Each federate can be subscribe an object that was defined in the FED file and each federate can send and object by publishing it over the RTI. If an object gets published any subscribed federate can get its contents.

As more days passes, we take control of such topics, and we believe we will create a great project.

Şenan Postacı

Warfare Units. Are They Walking, Swimming and Flying?

To begin with, last week was the most tiring times of our team. Apart from other projects and works we have to deal with, all our efforts were to make TRASTRAPS stand on its feet. Actually we achieved so, with our initial design report, which is like a little book :) Like other reports or works completed, initial design is also created by all of us, which we cannot separate part by part. Thus, I want to inform you a little bit about unit capabilities and unit hierarchy in our design.

There are three base entities concerning the units that construct both agents and trainee roles. (Sorry for some missing parts like what is trainee role or agent or modes, but we will give related information as time goes by, since some parts should still remain closed considering secrecy of the project.) These base entities are marine, ground and air forces as you can guess when thought of a warfare. And each base entity is modeled as deriving from the same unit class, but having different parameters to differ. According to these parameters, there exists different models of vehicles or units, which are ready to use when no modeling required at first. However, commanders are welcome to add their own models deriving from previous default ones, changing their parameters. There is no adding of parameter since new parameters may affect the physics of the simulation. Details of these models will probably be able to be given next week.

Differing models are not only due to the parameters but also by systems. With systems we mean any equipment that can be added to a unit in order to strengthen some characteristics of the unit. Of course the first system you should be thinking of is a gun or sensor, etc. which is correct, yes we have them in addition to five different models of systems. Again the type of systems will be given later. The hierarchy of systems are like units, where there are five base system and many deriving from them.

The domain search and parameter decision of units are again achieved by not only me, also with contribution of my teammates, but I have taken this part to share with you. I am eminently growing impatient to share our GUI designs and architecture to use RTI but I suppose next week, after our first presentation to public, we will be more relaxed to share detailed info about our project. I hope you are this impatient too to learn more about TRASTRAPS, which we start to take positive feedbacks from worldwide :) Thanks.

Ilke

Initial Design Report Time

It is time for us to write the initial design report. In order to write the report, we shoud have meet and took critical steps. So, we met this week and talked about what to do. We wrote some parts of the report and draw some essential diagrams. We decided how the GUI will be and I tried to write them clearly to the report. Also we decided how the scenarios will be. These scenarios will shape the project.
I did some research about integration of IDE and our software tools. They were not so good but I tried to use them as well as I can. However in portico, there are still some problems abot linking libraries that I am still working on. On the other hand, Irrlicht has a great tutorial for Netbeans IDE but it is implemented for DirectX. We are going to use OpenGL instead of DirectX, so I am working on Irrlicht to modify it to OpenGL.
We are getting closer to the implementation phase and I believe that when we start to implementation, we will swiftly show our differance.

--
Serkan Olgun

Designing process starts...

Finally we could have enough time to meet again and start our initial design report. After a tiring period, in the first meeting, we discussed the design details: how to decompose the system into self-working modules, GUI design, class, sequence and activity diagrams, etc. And without losing time we started our report immediately, and continue our research to shock everyone with our project.

Some of the class diagrams already drawn and we will probably finish them by the weekend and start the activity and sequence diagrams. Also, we planned that, each module in the project will be a separated and stand-alone process and they'll communicate via some special methods

Finally, it is so exciting to discover new technologies, and to try to apply them to our project.

To be continued...

Şenan Postacı

Way to the implementation

After doing nothing in the previous week, I enforced a great effort to bring out something concrete as I mentioned in my previous post.

First thing I made is to create a very simple federation using PORTICO project. Actually, we thought to use PORTICO project because of its documentation that we assumed it as a comprehensive and detailed documentation. However, after a slight surfing, I realized that user documentation of PORTICO is consist of only a single simple project that shows basic steps of creating federation and federate. It also explains how a federate joins to a federation, how synchronization points are announced, how federates publish objects over the RTI and register other objects, how time policy is controlled, etc. As PORTICO's documentation has come out as a bit disappointing, we think to look for other RTI documentations to go on.

Second development in our project is that we started to write our initial design report. In the initial phase of our design, we tried to ensure our goals about the project. Actually this refers to requirement analysis, but we try to do so much things in the same time that there can be missing points in development. We thought that if we cannot handle a generic terrain or model loading into the environment, there can be some initial terrains and models that can be used for specific goals such as boundary guard, union translation, etc. But users still have the ability of creating new scenarios on preloaded terrains with preloaded units.

Then, we thought about how to make our project modular. We intended to develop a layered architecture, although it is not mature currently, it is thought to have GUI layer, RTI layer, 3DEngine layer and a shared memory layer to provide communication between 3DEngine and RTI layer. Actually, this architecture does not cover all of the project, but it will modified in our following group meetings.

Considering all these factors, we started to write initial design report. Currently, all of us are working different parts of it. Furthermore, we are trying different combinations of operating system, environment and RTI implementations such as Windows, C++, Netbeans; Ubuntu, Java, Netbeans; etc.

I hope we will meet the deficit of the previous week.
Suat Gonul

Initialization of Initial Design

Yes we have started! One way we are integrating the IDEs and environments such that which is usable and convenient with which, and on the other way our designs are given start with GUI designs. The GUIs were decided a little bit before, but now the whole realization may be done in a couple weeks. What a commander and trainee do with the simulator, which areas restricted to which user, which user-specialized GUIs are handled how, all of these details will be given, they are just in progress. We have drawn them on paper and with visualizers, just waiting to be implemented. Of course the issue is that but starting from a point of view seems like a huge step from our perspective. Our other teams members are busy with unit and model design reflections, they will explain theirs a few hours later :)

We will give details of our initial design report just a few weeks later, be patient and wait for the virtual impact force! :)

Ilke