25 Aralık 2009 Cuma
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.
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:
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.
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.
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.
11 Aralık 2009 Cuma
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.
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...
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.
We will give details of our initial design report just a few weeks later, be patient and wait for the virtual impact force! :)
20 Kasım 2009 Cuma
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.
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...
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.
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 :)
13 Kasım 2009 Cuma
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 :)
12 Kasım 2009 Perşembe
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.
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.
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.
6 Kasım 2009 Cuma
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.
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
5 Kasım 2009 Perşembe
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.