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

Concrete steps

This week, we started to see something concrete about project's future and what we will realize about the project. We searched about game engines, terrain models, object models, domain information.

As my friends already mentioned, we wrote software requirements specifications document. Of course there are some missing points in it. Because of lots of homeworks, midterms in this week we could not cover in detail all of the subjects in detail. As I mentioned in the documents in some requirements, we will cover them in further cycles of spiral model of TRASTRAPS.

All we four prepared the srs document. So, I think it is pointless to write same things.
Suat Gonul

Writing SRS

It was a very exhaustive week because of the Requirements Specification Reports. We were very tired but when we look behind, we are proud of writing a professional, technical and satisfactory report. Each passing day relationship between Virtual Impact members getting stronger and requirements Specification Report was the last but most intesifier factor for this relationship.

In the report, we indicated all the initial steps of our project which involves, research conducted so far, the process flow that we planned, requirements we gathered and etc. Putting all together was a hard job, because it was our first huge report and it had to be well-organized and planned. Therefore we spent a lot of time together to plan each word and as a result a good report is written.

The most exciting part of the initial process was looking for 3D engines. As we found tools, we got self confident, and were glad to know what we can do with these great tools. Here is an example of a such tool we can make use of:



We should admit that forming the use cases and class diagrams was a hard job, but drawing them with "creately" was very enjoyable and easy. It seems we are going to use it a lot in this semester :)

During this period we did not just concentrate on the requirements, we also imagined all the final parts of the simulation, we believe it was the best part our meetings. It means we have a good dream of creating a great visual simulation and we will work very hard for that.

As a result, our Reqirements Analysis Report is not just a report, it represents what Virtual Impact can (and will) do. It is just the beginning and the visible part of the iceberg...

Şenan

Step by step to the end

This week, we gathered and talk about the future of our project. We defined our specifications and wrote a great Requirement Analysis report. All of us worked together and did a great job about Requirement Analysis Report.

First, we had to decide our 3D Graphics Engine and 3D Audio Engine. I did research about them. There are lots of engines available and ready to use but the problem is which one to use. They are classified as Graphics API, Programming Language Bindings, some libraries etc. The one we need has to have available support. Since we are new at this area, we need some documentations, manuals and tutorials to implement them. I found some great engines but they are not appropriate for us because of the lack of support. After some more research, we are agreed on one 3D Graphics engine and 3D Audio engine that have enough documentation and appropriate for our project.

After we decided on there critical points of the project, we can now imagine how the result will be approximately. I think imagining is something important in a project. Once we imagine the product of the project, the implementation will be easy for a group like us. We also agreed on the name of the product. It is TRASTRAPS. It means Training and Strategical Planning Simulation.

I believe we did a great job in such a busy week. We are getting closer to end week by week, so we need to work harder in order to achieve what we seek.

--
Serkan Olgun

Requirements and Initial Steps

This week was all about specifying requirements about the project. Our requirement analysis report can be downloaded from our website, which will be available as soon as the domain is provided as I said last week.

We have reflected the research we have done till now to the requirements analysis report, as well as determining the tools to be used. The most difficult part was coupling the project, which requires exact specifications. Nevertheless, this week we have put all of our work together and created a huge initial step to our project.

All of the report is written together, there was no individual work or subgroup study. Every decision is made by contribution of everyone, since we have decided the team model to be democratically decentralized. Of course we shared only the 'writing and drawing' part, to work parallel, but after deciding what to write or draw. I can say that my biggest 'solo' part was translating everything into LaTeX, since we pay attention to format of our report in addition to content. The design and cover of our report was my work too, where I used absolutely LaTeX :) Another design requiring issue was drawing of diagrams, where some use cases and a little part of class diagram was realized by me too. However, gantt chart was drawn by other team members, again compromising altogether on the timeline.

Related to content, every single aspect was discussed in the team but briefly what I have reduced to writing were;
- introduction chapter,
- process model and team model,
- major constraints,
- sponsor meeting overview,
- logging requirements and
- risk management issues.

In addition to these, we have decided on the design of our GUI menus which will be presented on the weekly meetings before sharing them with you :)

So what we have done in this week can be inspected from our requirements analysis report. We are willing to meet with you at this point next week, thanks :)

Ilke

Virtual impact is ready to strike!

As my friends already said that we tried write our software specification requirements, did some research about HLA-RTI implementation, decompose our system into modules, did some brainstorming roles of those modules within the whole system and started out to build our website in this week.

Some of the subjects are already explained by Senan and Ilke, nevertheless I want to make some additions about our efforts.

First of all, we thought that if we want to start immediately produce concrete application, we have to search and decide which HLA-RTI implementation to use. After making some investigation, we found tens of implementations but most of them do not suit us. Some of them are commercial, some of them are not completed and even have not a proper documentation or are not totally compatible with standards. The best choice which is the Portico Project glared at us. Because, it has a comprehensive documentation including beginning to Portico part. Actually, to start with this component is the most important for us. Also, it has Java and C++ support which is again most suitable for us. Here is a link of documentation part of it about Java: http://porticoproject.org/index.php?title=Getting_Started_With_Portico_Java. Furthermore, Portico project is compatible with 1.3, IEEE 1516 standards totally. It would be better for us to use such self completed open source implementations, otherwise we may have to make contribution to RTI implementation itself rather than dealing with our own project.

Last topic, I want to say something about is decomposing of our system into modules and roles of the modules. We decided to divide our system into 5 main parts: Federation, database management system, database itself, 3D model and graphic engine. I want to talk about them separately from a higher perspective.

Federation is composed of federates which are parts of simulation system such as soldier, helicopters etc. Those federates within federation communicate each other via RTI. Though, here are also some subcomponents of RTI for example RTI ambassador which serves services for communication, details will be included in our formal reports e.g software specification requirements.

Database management system will be the component that will be in relation with federates and 3D models to acquire related information from database thanks to methods that is harbored in it.

Database is the noncommercial off-the-shelf product. We may use a restricted version of Oracle or maybe MYSQL database. We have not decided on it yet.

3D models as understood will contain information about entities of simulation. But, the information does not have to be visual only. For example, it can be missile capacity of a plane.

Graphic engine will be the part that will visualize the simulation. Details of graphic engine has not been determined yet. We are still making some search about it discussing specifications about it.

That's all for me for this week. Have a nice day :)
Suat Gonul

SRS and UML Tool

As we are passing one more week, We are more confident about our project because we know much more as compared to last week. We made a great progress about our project.
First we started to write our Software Requirements Specifications report. I first read the IEEE Std. 830-1998 paper which is a guideline for SRS reports. IEEE Std. 830-1998 is not a SRS template but a paper which can make you understand what SRS is about and can help to write it. After I finished reading, I tried to find some SRS samples about warfare simulations. I did that because I wanted to know what can be included and how it can be written in a warfare simulation SRS. However, I could not find what I want exactly but I found some great samples of SRS reports.

After I examined them I was ready to write our own SRS report.
As we started to write the report, we had to decide what UML tool to use. Our most important concern was that the tool has to be cross-platform. The reason for that is Ilke uses a Mac Book Pro and rest of us use Intel and AMD based computers with Windows and Ubuntu operating systems. After some research I found a UML tool named as "Creately". Creately is a web-based diagramming and design application which is built on Adobe Flex (in our opinion). I can say that because 4 of us are familiar with Adobe Flex. Since it is web-based, our concern about cross-platform is taken care of. It can be used to create informational diagrams, flowcharts, organizational charts, UML designs, mind-maps and many other diagram types. The best part of it is collaboration capabilities. In public license, Max. 5 Collaborators can work. It has a 10MB limit but it is quite enough for us. We can export our designs to jpg-png image formats or pdf document format. That tool is really what we are looking for. We created our first diagram about system interface with Creately. There is a video about that tool:



That's all about from me for this week.
Serkan Olgun.

On preperation of writing SRS

This week I spent most of my time to pre-dedign and modulerize our term project to write a Software Requirements Specification (SRS). Also, it was very useful to read guidelines about writing good SRS. According to guidelines I have read so far, the project should be well-designed and all the requirements must be gathered before writing SRS. The most useful guideline was IEEE's and we decided to use it.

The requirements of the project may include each module's hardware dependencies, user interfaces, system interfaces etc. As we are going to implement a warfare simulator, user interfaces and graphical models are very important to implement. In addition, I thought and suggest my friends that, we can add RTI middleware system, it's usages, database management interfaces, graphics engine interfaces to our SRS as system interface.

Last but not least, I went on making research on HLA and RTI concepts to gain enough experience and knowledge before our inital design and it seems we should make more research on the concepts.

Şenan Postacı

Our Website Is On The Way! Behind The SRS Report :)

This week was a busy week in regard of the progress we have made about the project. Actually the study and research is done by whole group, but we will inform you in different subjects.

The part, actually the news, I will explain is a little bit more enjoyable :) Our web site is coming soon! I have been working on it for two weeks, and finally there exists a working draft from now on! We will share the address with you as soon as our department provides a domain for us, and from then, you can catch up with us from our website too. By means of an RSS feed of this blog I added and weekly reports (more formal formatted versions of what we tell here) we will be writing, you can have more information about the project. Moreover, the project definition, our contact information and lots of additional things are ready for you to be read. Just a little more time, we hope you will like :)

Other things we have done throughout this week is deciding on specifications of our project. Since our sponsors believe in us and our motivation, they are relaxed on specifications and we are absolutely free to implement everything we want, everything that we are to know we can do! With this conditions, we are our customer, our boss, our software team and our inspector. In this case, determining specifications and writing SRS report is our job too. Thus we have started writing down the whole SRS report by following the guideline of IEEE. Also while preparing, I needed an UML tool for Mac OS X, as a Mac user, for this reason we searched for a couple of UML and designing tools. In addition to plug-ins to Netbeans, Eclipse and other developing platforms; there are many tools like ArgoUML, Umbrella, Omnigraffle, Magic Draw, Visual Paradigm, Gliffy, etc. Trying each by ourselves, the best one in both practicality and license point of view, was definitely Creately, which Serkan will explain how to use a little bit.

So that's all by me for this week, other corporate studies that we have been working on will be told by other team members.

Ilke :)

Initial Learning About Term Project Components: HLA, RTI, Agents

HLA (High Level Architecture) has become a familiar subject for me after my first summer practice. At that time, I got a little information which is HLA is a standard and it provides some standards enabling communication between different parts of a simulation system like computers, joysticks, simulation cabins, etc. As far as I read in the previous week, I acquired some additional information on this subject.

Firstly, I understood that my old information was a little missing that HLA provides communication between simulation components. It is the middle-ware named RTI (Run Time Infrastructure) having services that are described by HLA Interface Specification. HLA also describes federates which are parts of as reusable software units and federates communicate with each other through the services of RTI. Implementation of services of RTI are not obligated to be the same of each other, in other words there are several RTI implementations which can be chosen with respect to different kinds of needs. So, it is necessary to all federates within a federation to use the RTI same implementation.

Lastly, I had no information about agents of computer science. After a little investigation, I found out that agents are classes having ability of learning or decision making. They usually have the characteristics of autonomy, social ability, reactivity, pro-activeness, etc. So, they do their jobs without intervention of a human or some other trigger, they can interact with other agents, even they show goal directed behaviours in addition to act in response manner.

Suat Gonul

For starters, HLA and RTI

Since this is the first week, I did some research on what we'll use for out project. So, I did some research on HLA (High Level Architecture) and RTI (Run Time Interface).

After some Google-ing, I found very useful information. First, I found out that HLA is an architecture which was first introduced by U.S. DMSO (Defense Modeling and Simulation Office) but it is an IEEE standart now (IEEE 1516). I figured that HLA is simply an architecture for distributed computer simulation systems which allows computer simulations to communicate to other computer simlations. However, HLA is not enough for computer simulations by itself. RTI (Run Time Interface) is needed to manage those communication. RTI is the main component of HLA. HLA also has 2 other components (i.e., Object Model Template (OMT) and HLA Rules).

After some research about these issues, I tried to discover some RTI implementations. First, I checked out Chronos RTI by Magnetar Games. It uses IEEE 1516 standart and C++ .NET. Since it is a licensed product, I downloaded trial version of it. It allows you to use it for 10 minutes. I tried to figure how it works. I read some parts of its manual and now tried to figure how to implement.

After that, I found a really good paper entitled as "Selecting a HLA Run-Time Infrastructure" by Michael Imbrogno, Wayne Robbins and Gerard Pieris (Ottowa-Canada). It really helped me have an idea about HLA and RTI. I am sure that I'll use that paper for my future needs about the project

Serkan Olgun.

Hello World, Hello HLA RTI!

For the first week of our project, I have inspected some sources related to HLA based RTI implementations, done some market search and looked for intelligent agents a little bit. Of course most of our effort is given to brainstorming during this process, because "what" to implement is still a larger question than "how" to implement, before giving out an SRS.

I see no need to explain concepts like what HLA standard stands for, for which purpose RTI is used, etc., but I want to share some useful sources that we (or you, if you are interested in similar topics) can use in future development steps. The first one is Portico, a fully supported, open source, cross-platform HLA RTI implementation. You can get more info from http://porticoproject.org/ . It is well documented and open source, however it is better to keep in mind that, to use a tool that is more preferred and suggested by sponsors may be well-integrated and ease our work.

Also for RTI implementations, the evaluation and comparison of them are briefly summarized in a paper we found at http://www.scs.org/confernc/hsc/hsc02/hsc/papers/hsc017.pdf . And the last source we have examined about HLA based simulating is http://dss.ll.mit.edu/dss.web/96.14.103.RTI.Introduction.html where every step is explicitly told.

Considering HLA terminology, agents (intelligent objects) are creatures(!) that we are not so familiar with. To have some idea about how artificial intelligent is dealt with in such simulations, Distributed Artificial Intelligence And The HLA: Bridging The Gap is an invaluable article we can consult.

So that's all from my research part, next week we will have started to take a step to implementation and design decisions, I hope.

Ilke :)

A mini-research on HLA an RTI

At the very initial step of our term project, I made some research about very important topics such as HLA (High Level Architecture), RTI (Run-time Infrastructure) to get familier with them. HLA is a distributed architecture for computer simulation systems. In HLA each unit is called a federate and each federate can communicate through a middleware also known as RTI which is the fundemental component of HLA. Federates can cooperate with each other thanks to the services that are provided by RTI. These services allow federates to exchange data and communicate in run time.

An interface specification of HLA defines how HLA simulator can communicate with RTI and these specifications are object-oriented. As one can guess many vendors develop their RTI implementations using JAVA and C++ languages.

There are several RTI implementations and it is worth to note that, RTI vendors may follow different design patterns to develop their RTI implementations. In addition, it is not necessary to implement each federation by the same RTI implementation, a different but suitable one can be used. However, using different RTI implementations may lead to interoperability issues, so vendors’ interoperability specifications about different versions or products of other vendors should be read.

Şenan