JDMS Original article Journal of Defense Modeling and Simulation: Applications, CADAC: Multi-use Architecture for Methodology, Technology XX(X) 1 –17 Constructive Aerospace Simulations © 2011 The Society for Modeling and Simulation International DOI: 10.1177/1548512910395641 dms.sagepub.com Peter H Zipfel Abstract In today’s network-centric world, aerospace vehicles interact with many objects. They navigate by overhead satellites, synchronize their flight paths with other vehicles, swarm over hostile territory and attack multiple targets. Studying these engagements with high-fidelity constructive simulations has become an important task of modeling and simulation (M&S). The simulation framework Computer Aided Design of Aerospace Concepts (CADAC) has its roots in FORTRAN code that dates back to the 1960s and was used by industry and the U.S. Air Force to simulate aerospace vehicles in all flight environments. To adapt CADAC to the new environment, a complete rewrite was carried out in C++, taking advantage of object-oriented programming techniques. The architecture of CADAC++ is based on the hierarchical structure of inherited classes. The vehicles (aircraft, missiles, satellites or ground targets), inherit the six-degree-of-freedom (6-DoF) equations of motion from the classes ‘Flat6’ or ‘Round6’, conveying either the flat or elliptical Earth model. In turn, these classes inherit the communication structure from the base class ‘Cadac’. The components of the vehicle, e.g., aerodynamics, propulsion and autopilot, are represented by modules, which are member functions of the vehicle class. Communication among the modules occurs by protected module-variable arrays. Every instantiated vehicle object is encapsulated with its methods and data. To communicate between vehicles, data packets are loaded onto a global data bus for recall by other vehicles. Input occurs by ASCII file and output is compatible with CADAC Studio, a plotting and data processing package. CADAC++ is chiefly an engineering tool for refining the components of the primary vehicle and exploring its performance as it interacts (possibly repeatedly instantiated) with the multi-object environment. Its modular structure enables reuse of component models across simulations. In the 10 years of development, CADAC++ based constructive simulations have been built for many types of aerospace vehicles and integrated with mission-level simulations. Keywords aircraft and missile simulations, engagement simulations, high fidelity modeling, constructive simulations, C++ programming language, six degrees of freedom, CADAC, CADAC studio, three-stage booster, dual role missile, self defense missile, hypersonic cruise missile, multi-object programming, run-time polymorphism classes, communication bus. 1. Introduction High-fidelity, six-degree-of-freedom (6-DoF) simulations ENDOSIM simulation.a The U.S. Air Force also adopted it play an important part in the development of weapon to its own needs and named the simulation Computer Aided systems. These so-called constructive simulations are used Design of Aerospace Concepts (CADAC). in technology trade studies, preliminary design, hardware- in-the-loop evaluation, flight testing and training.1 a. AMTEC Corporation. Endo-atmospheric Non-nuclear Kill Simulation. Report No. TR 1147. Huntsville, AL: U.S. Army The first all-digital, constructive simulations were cre- Strategic Defense Command, August 1989 (restricted distri- ated by the National Aeronautics and Space Administration bution). (NASA), U.S. Department of Defense (DoD) and industry. In 1966 Litton Industries developed the architecture for a U.S. Air Force Research Laboratory, Eglin AFB, FL, USA missile simulation in FORTRAN IV that had all of the fea- Corresponding author: tures of a full 6-DoF simulation. It was the source of many Peter H Zipfel, U.S. Air Force Research Laboratory, derivatives by Hughes Aircraft, North American Aviation Eglin AFB, 73 Country Club Road, Shalimar, FL 32579, USA. and Aerospace Corporation. Noteworthy is the U.S. Army Email: [email protected] Report Documentation Page Form Approved OMB No. 0704-0188 Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. 1. REPORT DATE 3. DATES COVERED FEB 2011 2. REPORT TYPE 00-00-2011 to 00-00-2011 4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER CADAC: Multi-use Architecture For Constructive Aerospace 5b. GRANT NUMBER Simulations 5c. PROGRAM ELEMENT NUMBER 6. AUTHOR(S) 5d. PROJECT NUMBER 5e. TASK NUMBER 5f. WORK UNIT NUMBER 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION U.S. Air Force Research Laboratory,Eglin AFB, 73 Country Club REPORT NUMBER Road,Shalimar,FL,32579 9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S) 11. SPONSOR/MONITOR’S REPORT NUMBER(S) 12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release; distribution unlimited 13. SUPPLEMENTARY NOTES The Journal of Defense Modeling and Simulation: Applications, Methodology, Technology February 9, 2011. 14. ABSTRACT In today?s network-centric world, aerospace vehicles interact with many objects. They navigate by overhead satellites, synchronize their flight paths with other vehicles, swarm over hostile territory and attack multiple targets. Studying these engagements with high-fidelity constructive simulations has become an important task of modeling and simulation (M&S). The simulation framework Computer Aided Design of Aerospace Concepts (CADAC) has its roots in FORTRAN code that dates back to the 1960s and was used by industry and the U.S. Air Force to simulate aerospace vehicles in all flight environments. To adapt CADAC to the new environment, a complete rewrite was carried out in C++, taking advantage of object-oriented programming techniques. The architecture of CADAC++ is based on the hierarchical structure of inherited classes. The vehicles (aircraft, missiles, satellites or ground targets), inherit the six-degree-of-freedom (6-DoF)equations of motion from the classes ?Flat6? or ?Round6?, conveying either the flat or elliptical Earth model. In turn, these classes inherit the communication structure from the base class ?Cadac?. The components of the vehicle, e.g., aerodynamics,propulsion and autopilot, are represented by modules, which are member functions of the vehicle class. Communication among the modules occurs by protected module-variable arrays. Every instantiated vehicle object is encapsulated with its methods and data. To communicate between vehicles, data packets are loaded onto a global data bus for recall by other vehicles. Input occurs by ASCII file and output is compatible with CADAC Studio, a plotting and data processing package. CADAC++ is chiefly an engineering tool for refining the components of the primary vehicle and exploring its performance as it interacts (possibly repeatedly instantiated) with the multi-object environment. Its modular structure enables reuse of component models across simulations. In the 10 years of development, CADAC++ based constructive simulations have been built for many types of aerospace vehicles and integrated with mission-level simulations. 15. SUBJECT TERMS 16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER 19a. NAME OF ABSTRACT OF PAGES RESPONSIBLE PERSON a. REPORT b. ABSTRACT c. THIS PAGE Same as 17 unclassified unclassified unclassified Report (SAR) Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18 2 Journal of Defense Modeling and Simulation: Applications, Methodology, Technology XX(X) CADAC, since its inception in 1978, has morphed main vehicle – missile, aircraft, spacecraft – it also portrays through many stages of improvements, but has remained the interactions with outside elements, such as satellites, faithful to its FORTRAN language. But in today’s network- targets and sister vehicles. The main vehicle is modeled centric world, aerospace vehicles interact with many with greatest fidelity, while the secondary objects have sim- objects: they navigate by overhead satellites, synchronize pler representations. their flight paths with other vehicles, swarm over hostile ter- The synthesis and conceptualization process places ritory and attack multiple targets. Studying this connectivity distinct requirements on the simulation architecture. has become an important aspect of high-fidelity simula- To support the design engineer in evaluating the aerody- tions. FORTRAN, lacking the power of object-oriented namics, propulsion, guidance and control components, programming, has therefore been replaced by C++. A new CADAC++ should mirror the same modular structure and architecture, called CADAC++, was created to enable the closely control the interfaces between them. It should conceptualization of aerospace vehicles. encapsulate each vehicle object for multiple instantiation Other organizations followed the same trend and con- and provide global communication between them. Input verted from FORTRAN to C++, or started entirely new and output must be flexible and compatible with CADAC frameworks in C++. Best known is JSBSim,2 an open- Studio, a post-processing and analysis tool. More specific source aircraft simulation that is also the basis of the Flight requirements follow. Gear Simulator.3 The U.S. Army created an entirely new framework called CMD C++ Model Developer.4 At its core 2.1 Face to the User is a kernel that supports any kind of modeling described by time-phased differential equations. Its distribution is unre- Users like to focus on the evaluation of the main vehicle stricted. Another U.S. Army organization, MSIC (Missile without being burdened by the details of the simulation’s and Space Intelligence Center) contracted with Dynetics execution. They want control of the input/output and the for the MSIC++ Generic Simulation,b which is a multi-pur- vehicle modules that define the subsystems. pose missile simulation environment, but not generally There should be only one input file that controls the available to the public. simulation. It displays the run title, an option line for direct- CADAC is a joint development by the U.S. Air Force and ing the output, the calling sequence of the modules, the the University of Florida. Its framework architecture and sizing of the integration step and the initializing of the vehi- some of the academic simulations are publicly available. The cle parameters. The integration step size should be variable. original FORTRAN version and the plotting and analysis The aerodynamics and propulsion tables should be kept programs, CADAC Studio, can be downloaded from the separate for safekeeping rather than being part of the source American Institute of Aeronautics and Astronautics (AIAA).5 code. Their file names, given in the input file, would load The C++ simulations are available as a three-part Self-Study the data decks into memory prior to execution. Multiple Series, based on lectures at the University of Florida.6-8 instantiation of the vehicle objects should be accomplished CADAC Studio also supports these C++ simulations. by simply duplicating the vehicle input data and changing CADAC++, in its 10-year history, has been used as a selected variables as necessary. simulation test bed for missiles, aircraft, unmanned aerial The output control should be simple yes/no choices. vehicles (UAVs) and spacecraft. Its modular structure An option line would provide output to the screen of the enables reuse of subsystem models and its well defined primary and secondary vehicles, together with the event interfaces allow integration into higher level simulations, messages that indicate their changing flight status. like FLAMES®-based mission models.9 There should also be an option to archive the screen This paper summarizes the process that led from require- output to a file. Plot files as well as statistical data files ments definition to architecture development and full-up would be written for individual vehicles and merged constructive simulation. Some examples are presented that together for multi-vehicle displays. These output files highlight the features of CADAC++. should be compatible with the existing CADAC Studio for two- and three-dimensional plotting and statistical analysis. 2. Requirements The components of the vehicles should be mirrored by CADAC++ is an engineering tool aiding in the develop- modules that model their features. Strict control of the ment of aerospace vehicles. Although it focuses on the interfaces will make the modules interchangeable amongst simulations. The modules should define these interface variables, execute integration of state variables and enable b. Dynetics. MSIC++ Generic Simulation Documentation. Report No.: MSIC C.M. Control Number COV0. Dynetics, table look-up. Any vehicle changes that the user wants to 18 April 1995 (restricted distribution). make should be confined to these modules. Zipfel 3 2.2 Multiple Encapsulated Vehicle Object 2.8 Matrix Utility Operations Each aerospace vehicle (be it missile, aircraft or spacecraft) The full power of C++ should be applied to matrix opera- should be built up from a hierarchy of classes, starting with tions. Matrix utilities should be tailored to the specific needs the base class Cadac, followed by the equations of motion, of flight simulations and not burdened by C++ container and completed by the vehicle itself. Each vehicle is a C++ classes. Efficient pointer arithmetic will speed up the execu- object with its data (aerodynamics and propulsion) and tion and allow unlimited stringing of matrix operations. methods (modules) encapsulated. Run-time polymorphism should be used to sequence through the vehicle objects 2.9 Documentation and Error Checking during execution. The module-variables, being the key interfaces between the modules, should be fully documented. The definitions pro- 2.3 Modularity of Vehicle Components vided in the modules should be collected in a single output The modules, representing the vehicle components, should file. The module-variables in the input file should also be be public member functions of the vehicle classes. Their documented with the same definitions. interfaces, the module-variables, would be stored in pro- Error checking should identify module-variables that tected data arrays that are available to all modules of the have not been assigned the correct names or locations in the vehicle object. During execution, the modules should input file or the modules. Incompatible matrix operations define all module variables, make initializations, integrate should be flagged, as well as problems with opening of file state variables and conduct post-run calculations. streams. A variable should be displayed on the console that indicates the computational precision of the attitude calculations. 2.4 Event Scheduling Just as aerospace vehicles transition though flight phases, 3. Architecture the simulation should be able to sequence through such events. These events should be controlled by the input file These requirements can be satisfied with object oriented without any code changes in the modules. Relational opera- programming in C++. Hierarchical class structures, encap- tors such as <, =, > would be applied to the module-variables sulation of data and methods, run-time polymorphism, and trigger the events. overloading of functions and operators, are all features used in CADAC++ to build a simulation environment suit- able for flight vehicle synthesis. 2.5 Global Communication Bus CADAC++ programming follows the International Because vehicle objects are encapsulated into classes, a Standard for C++ defined by the American National global communication bus should enable the transfer of Standards Institute/International Organization for data. Each vehicle should be able to publish and subscribe Standardization (ANSI/ISO) Committee in 1998 and imple- to any of the module-variables. mented by most compilers like Microsoft Visual C++. Thus, portability is assured and low-cost operation is made possible. 2.6 Table Look-up Each requirement is now addressed separately, with par- Table utilities should provide for one, two and three indepen- ticular focus on the classes that structure the features of dent variable look-up. Tables must be stored in separate files CADAC++ and modifications easily accomplished. Simple syntax should make the table look-up easy to program in the CLASS DESCRIPTION modules. Cadac,... Hierarchical class structure of vehicles 2.7 Monte Carlo Capability Vehicle Hosting a pointer array of To automate the evaluation of random processes, a Monte type Cadac Carlo methodology should be implemented. Distributions Module Storing module information like uniform, Gaussian, Rayleigh, exponential and Markov Variable Declaring module-variables should be identified in the input file by keywords. Stochastic Event Storing event information output data must be written to files compatible with Packet Declaring data packets for global CADAC Studio for post-processing. communication bus 4 Journal of Defense Modeling and Simulation: Applications, Methodology, Technology XX(X) TITLE 2 Missiles (RF seeker) against 2 targets with 1 recce MONTE 1 123456 OPTIONS y_scrn y_events y_tabout y_plot y_merge y_doc y_comscrn y_traj y_stat MODULES Environment def,exec kinematics def,init,exec propulsion def,init,exec aerodynamic def,init,exec seeker def,exec filter def,exec ins def,init,exec datalink def,exec guidance def,exec control def,exec actuator def,exec forces def,exec euler def,exec newton def,init,exec intercept def,exec END TIMING scrn_step 2 plot_step 0.05 traj_step 0.2 int_step 0.001 com_step 2 END VEHICLES 5 MISSILE6 Missile #1 tgt_num 1 //’int’ Target tail # attacked by ‘this’ missile module combus /Initial conditions sbel1 0 //Initial north comp of SBEL - m module newton sbel2 0 //Initial east comp of SBEL - m module newton sbel3 -4000 //Initial down comp of SBEL - m module newton dvbe 250 //Missile speed - m/s module newton /Aerodynamics AERO_DECK drmdr6_aero_deck.asc /Propulsion PROP_DECK drmdr6_prop_deck.asc ………………………………………………………………………………………………………………………………………………………………………………………………… END ENDTIME 18 STOP Zipfel 5 Datadeck Hosting a pointer array of type Table execution sequence of the modules. For sophisticated Table Storing tabular data simulations, the calling sequence may become very impor- Markov Storing Markov data tant. Each of the timing events can be controlled separately Matrix Storing matrix operations in order not to overload the output devices. With the key- Document Storing module-variable definitions word begins the loading of the vehicle objects. VEHICLES Only a fraction of the first object is shown, MISSILE6 though there are five vehicles to be loaded. By simply rep- 3.1 Face to the User licating or other objects and incrementing the MISSILE6 The user friendly requirements are met with an architecture integer after , new objects are loaded. Note how VEHICLES that enables easy use and modification of the simulations. the file names that contain the tables are identified by the The input file has all the features that control the execution: keywords and . AERO_DECK PROP_DECK title, option line, module call, timing control and vehicle The user who wants to modify a vehicle component has initialization. only to deal with the corresponding module. The module The option line provides nine possible outputs. During run- contains all code and interfaces that define the components, time, , and write data to carries out the table look-up and integrates the state variables. y_scrn y_event y_comscrn the console; Re-use of modules for other simulations is facilitated by the y_tabout, y_plot, y_merge, y_ and write the output to ASCII strict control and detailed documentation of the interfaces. doc, y_traj y_stat files for later processing by CADAC Studio. An important As an example, let us look at the much abbreviated feature is the control that the user has over the loading and ‘newton’ module. void Flat6::def_newton() { //Definition and initialization of module-variables flat6[210].init(“VBEBD”,0,0,0,” Velocity deriv. - m/s^2”,”newton”,”state”,””); flat6[213].init(“VBEB”,0,0,0,”Missile velocity - m/s”,”newton”,”state”,””); flat6[230].init(“FSPB”,0,0,0,”Specific force - m/s^2”,”newton”,”out”,””); flat6[239].init(“hbe”,0,”Height above ground - m”,”newton”,”out”,”scrn,plot”); flat6[247].init(“mfreeze_newt”,”int”,0,”Saving mfreeze “,”newton”,”save”,””); } void Flat6::init_newton() { //initializations .................... } void Flat6::newton(double sim_time,double int_step) { //local module-variables Matrix FSPB(3,1); double hbe(0); //localizing module-variables //from initialization .................... //getting saved value int mfreeze_newt=flat6[247].integer(); //input from other modules Matrix TBL=flat6[120].mat(); //state variables 6 Journal of Defense Modeling and Simulation: Applications, Methodology, Technology XX(X) Matrix VBEBD=flat6[210].vec(); Matrix VBEB=flat6[213].vec(); //------------------------------------------------------------------------ .................... //integrating acceleration in body coord to obtain velocity FSPB=FAPB*(1/vmass); Matrix VBEBD_NEW=FSPB-ATB+TBL*GRAVL; VBEB=integrate(VBEBD_NEW,VBEBD,VBEB,int_step); VBEBD=VBEBD_NEW; .................... //------------------------------------------------------------------------ //loading module-variables //state variables flat6[210].gets_vec(VBEBD); flat6[213].gets_vec(VBEB); //saving values flat6[247].gets(mfreeze_newt); //output to other modules flat6[230].gets_vec(FSPB); flat6[239].gets(hbe); //diagnostics .................... } The module consists of three parts: the definition of hierarchical class structure derived from the common module variables, the initialization and the integration. In abstract base class . Cadac the creation of capitalized vari- This hierarchical class structure in CADAC depends on the def_newton() Matrix ables, lower case and variables is shown. particular simulation. For instance, the CADAC 6-DoF air- real integer Any new module-variable will be added here. Conversion craft simulation consists of a single branch ← Cadac of trajectory parameter from the input file to more suitable ← , where models the equations of Flat6 Plane Flat6 variables occurs in . The integration motion over the flat Earth, and models the compo- init_newton() Plane takes place in with a call to the function nents of an airplane. The more elaborate CADAC missile newton(…) . This part shows the three sections of the engagement simulation has multiple branches. Its main branch integrate(…) code: creating or localizing variables, executing code and represents the high-fidelity 6-DoF missile model ← Cadac loading module-variables to the array ← . The supporting vehicle branches flat6[]. Flat6 Missile More detail of the modules is provided below under the ← ← and ← Cadac Flat3 Target Cadac Flat3 heading Modularity of Vehicle Components. ← are the 3-DoF target and reconnaissance aircraft. Recce As another example, the 3-DoF CADAC cruise missile simu- lations over the round rotating Earth has the three branches: 3.2 Multiple Encapsulated Vehicle Object ← ← ← Cadac Round3 Cruise, Cadac Round3 The rewriting of CADAC was motivated by the unique fea- ← and ← ← Target Cadac Round3 Satellite. ture of C++ allowing encapsulation of vehicle objects. The vehicle objects, declared by their respective classes, Encapsulation means binding together data and functions are created during run-time by the polymorphism capability while restricting their access. The aerodynamic and propul- of C++. Polymorphism (many forms, one interface) uses sion data are bound together with the table look-up functions inheritance and virtual functions to build one vehicle-list of and many other functions that support the missile and air- all vehicle objects, be they 6-DoF missiles, 3-DoF targets craft objects. In turn, these objects are created from a and recce aircrafts or satellites. At execution, this vehicle- Zipfel 7 list is cycled through at each integration step in order to architecture is that all vehicle objects have to be instanti- compute the respective vehicle parameters. ated at the beginning of the run. The class facilitates the run-time polymor- Vehicle phism. It has a private member , which **vehicle_ptr 3.3 Modularity of Vehicle Components is a pointer to an array of pointers of the class that Cadac contains the pointers to all the vehicles objects. It also A key feature of CADAC is its modularity, which reflects declares the offset operator the component structure of an aerospace vehicle. Just as the Cadac *operator[](int that returns the pointer to the vehicle object located hardware is divided into subsystems (such as propulsion, slot) at the offset in the vehicle-list. autopilot, guidance and control) CADAC simulations are slot In the object broken into propulsion module, autopilot module, etc. This main(), Vehicle vehicle_ is created, initialized and its is extended to include non-hardware modules like aerody- list(num_vehicles) constructor allocates memory for the array of pointers namics, Newton’s and Euler’s equations of motion and environmental modules. This one-for-one correspondence vehicle_ptr=new Cadac *[num_ ensures clean interfaces between the modules. vehicles]; Each module is a pure virtual member function of the Then the global function abstract base class and is overridden in the derived Cadac *set_obj_type(…) Cadac interrogates the input file to identify the vehi- class, be it input.asc Flat6, Flat3, Missile, Target, cle types by keywords such as MISSILE6, TARGET3, or others. If the derived class does not use a module, Recce RECCE3, etc. It allocates memory to the vehicle objects the module will return empty. , etc. and returns point- The calling sequence of the modules is controlled by Missile, Target, Recce ers of base class These pointers are stored in their sequential listing in the input file . Each Cadac. input.asc the array by the member module may consist of four parts: the definition part (iden- vehicle_ptr[] Vehicle function tified by , the initialization part ( , the execution def) init) part ( and the last call . All are called only exec) (term) vehicle_list.add_vehicle once, with the exception of which is called during exec (*vehicle_type); every integration step. Now the object is ready to be The structure declares the name and the four Vehicle vehicle_list Module addressed by its offset operator For instance, the vehi- parts of the module. Reading from the mod- []. input.asc, cle specific data are read from by ules are loaded into the by the global input.asc module_list function vehicle_list[i]->vehicle_ data(input); order_modules(input,num_ modules,module_list); where is the th vehicle object in the sequence i (i+1) established in . Here is the explanation of the At creation of the vehicle object, at module initialization input.asc logic flow. The offset operator takes and returns the and at each integration cycle the is inter- [] i module_list of the th vehicle. Although the rogated for the module names. For example, the definition vehicle_ptr[i] (i+1) array is of the base class , the of the aerodynamic module occurs in the vehicle’s vehicle_ptr Cadac compiler has knowledge of the individual pointer being constructor of the derived class or . Missile, Target Recce Such is the marvel of run-time polymorphism! Another if((module_list[j]. important example is the call of a vehicle module, say the name==”aerodynamics”)&&(module_list[j]. aerodynamic module definition==”def”)); def_aerodynamics(); vehicle_list[i]->aerodynamics(); If the th vehicle is the MISSILE6, a pointer of type Then the initialization of the module takes place in (i+1) main() Missile is furnished that is used to call the member function of the derived class . On if((module_list[j]. aerodynamics() Missile the other hand, if the vehicle is the TARGET3, the pointer name==”aerodynamics”)&&(module_list[j]. is of type and points to the member initialization==”init”)) Target Target function aerodynamics(). vehicle_list[i]->init_aerodynamics(); Through run-time polymorphism any number of differ- ent vehicles can be called using the common pointer array where is the pointer to the vehicle vehicle_list[i] of type . These calls are executed during initializa- object. During integration, the module is called inside the Cadac tion and at every integration step. A limitation of this function which is called directly from execute(…) main() 8 Journal of Defense Modeling and Simulation: Applications, Methodology, Technology XX(X) if(module_list[j]. flat6[230].gets_vec(FSPB); name==”aerodynamics”) flat6[120].gets_mat(TBL); vehicle_list[i]->aerodynamics(); Module-variables provide the sole data transfer Currently, the terminal calls are not needed. between the modules of a vehicle object. For documenta- Data are transferred between modules by module-vari- tion they are recorded in sequential order in doc.asc ables and stored in arrays of type . Each derived with their definitions and other relevant information. Variable object from the base class has an array with its own Between their label and array location, there is a unique Cadac name, such as one-to-one relationship. Any deviation from that rule is flat6[], missile[], target[], etc. They are protected members of . The arrays flagged in . Cadac doc.asc are sized by global constants NFLAT6, NMISSILE, , etc. and each module is assigned a block of NTARGET 3.4 Event Scheduling indices in its respective arrays. The class declares the module-variable As aerospace vehicles fly their trajectories, they may Variable object. Its private members store the label, the initial value, sequence through several events towards their destinations. the type of variable ( , , 3 x 1 vector, 3 x 3 Just think of rockets staging, airplanes taking off, cruising int double matrix), the definition and units, the module where the and landing and missiles passing through midcourse and value is calculated, its role (input data, state variable to be terminal phases towards the intercept. Events in CADAC++ integrated, diagnostic, output to other modules and data are interruptions of the trajectory for the purpose of reading saved for the next integration cycle), the output direction new values of module-variables. They can only be sched- (screen, plot file, communication bus) and two error codes. uled for the main vehicle object. The maximum number of The public methods of contain a four times events is determined by the global integer , while Variable NEVENT overloaded function for integer, double, vector the number of new module-variables in each event is lim- init(…) and matrix variables which are used for the variable defini- ited by the global integer . NVAR tions in the definition part of the module, e.g. An event is defined in the input file by the input.asc event block starting and ending with the keywords … IF . Appended to is the event criterion. It consists missile[110].init(“ca”,0,”Axial ENDIF IF of the watch variable (any module-variable except of type force coefficient”,”aerodynamics”, Matrix) and a relational operator followed by a numerical ”out”,”plot”); value. For instance, Other public methods of Variable govern the reading and loading of the module-variables inside a module. To IF dbt < 8000 make the module-variables local variables, the member mseek 12 //’int’ =x2:Enable, functions and integer(), real(), vec() mat() =x3:Acquisition, =x4:Lock module seeker are used. For instance, ENDIF int mfreeze_newt=flat6[247]. means, if the range to the target is less than 8000 m, the integer(); seeker is enabled. The supported relational operators are double grav=flat6[55].real(); <, =, >. The class supports the creation of type Matrix TBL=flat6[120].mat(); Event Event objects. The pointer of each event is stored in the Matrix FAPB=flat6[200].vec(); event_ , which is a protected member of ptr_list[NEVENT] By convention, scalar variables are named with all lower- the vehicle class. The private members of the class Event case letters, while upper-case letters designate matrices. store information about the event, such as watch variable, Only 3 x 1 vectors and 3 x 3 matrices are permitted as relational operator, threshold value and new module-vari- module-variables. ables. The public methods are ‘set’ and ‘get’ functions for The loading of the local module-variables into the pro- the data. To expedite execution, the new module-variables tected arrays uses the member functions are not stored by their name, but by their offset index in the gets(…), and where is module-variable array. Therefore, rather than cycling gets_vec(…) gets_mat(…) gets(…) overloaded and serves both and types. For through all the module-variables, the new module-variables int double instance, are directly picked out by their offset indices. These index lists are also part of the private data members of . Event flat6[247].gets(mfreeze_newt); Event data are read in from by main() input.asc flat6[248].gets(dvbef); the vehicle member function