Design Plan JTLS-2013-11707 ROLANDS & ASSOCIATES Corporation JTLS-GO 6.0.0.0 27 25 May 2020 JTLS-2013-11707 Improve Simscript Debugging Capability Ellen F Roland 1.0 Summary of Model Change Request Previous versions of JTLS-GO used the Simscript II.5 programming language. Several years ago ROLANDS & ASSOCIATES Corporation (R&A) asked CACI Corporation to provide a more robust debugging capability. Specifically, R&A asked for conditional breakpoint access. In other words, the R&A design team was asking to be able to break as Line 203 of routine Air Mission Detection if the local variable THE.FS is equal to 3. This capability was provided by CACI as part of Simscript III. JTLS-GO needs to move to the Simscript III programming language to improve the debugging capability for the design team. 2.0 Design Summary The reason the JTLS-GO did not immediate convert to the Simscript III programming language was because there were several significant changes to the programming language. Specifically, the following Simscript II.5 capabilities used by JTLS-GO have been deprecated in Simscript III: • Events • Bit-packing of variables • Variable equivalence • Permanent entities • Single Event Set Moving to Simscript III was deemed too large of a job to accomplish at the same time R&A was implementing Global Operations within JTLS by converting its limited hexagon terrain to the gridded terrain, This ECP takes on the large, but model insignificant task of converting all JTLS-GO Simscript code to Simscript III.
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Design Plan JTLS-2013-11707 ROLANDS & ASSOCIATES Corporation
JTLS-2013-11707 Improve Simscript Debugging Capability
Ellen F Roland
1.0 Summary of Model Change Request
Previous versions of JTLS-GO used the Simscript II.5 programming language. Several years agoROLANDS & ASSOCIATES Corporation (R&A) asked CACI Corporation to provide a more robustdebugging capability. Specifically, R&A asked for conditional breakpoint access. In other words,the R&A design team was asking to be able to break as Line 203 of routine Air Mission Detectionif the local variable THE.FS is equal to 3.
This capability was provided by CACI as part of Simscript III. JTLS-GO needs to move to theSimscript III programming language to improve the debugging capability for the design team.
2.0 Design Summary
The reason the JTLS-GO did not immediate convert to the Simscript III programming languagewas because there were several significant changes to the programming language. Specifically,the following Simscript II.5 capabilities used by JTLS-GO have been deprecated in Simscript III:
• Events
• Bit-packing of variables
• Variable equivalence
• Permanent entities
• Single Event Set
Moving to Simscript III was deemed too large of a job to accomplish at the same time R&A wasimplementing Global Operations within JTLS by converting its limited hexagon terrain to thegridded terrain,
This ECP takes on the large, but model insignificant task of converting all JTLS-GO Simscript codeto Simscript III.
JTLS-GO 6.0.0.0 27 25 May 2020
ROLANDS & ASSOCIATES Corporation Design Plan JTLS-2013-11707
3.0 Detailed Design
The term deprecated does not mean non-functional. Each of the deprecated items mentionedabove used by JTLS-GO still work, but the design team felt that it was appropriate to remove asmany of the deprecated items as possible. This primarily insures that if the deprecated items areever removed from the Simscript III, JTLS-GO will not be caught in a corner with few choices.
Each of the deprecated items is discussed in the following sections along with the methodimplement to remove the deprecated concepts.
3.1 Events
It is impossible to remove events from JTLS-GO. To understand why this is true, the reader needsto understand some basic simulation concepts. JTLS-GO is an event-step simulation with time-step overlays. An event is an instant in time. Then model schedules events to occur and thensorts the events by execution time. Simscript determines the next event based on the scheduledtime of the event
3.2 Bit Packing Of Variables
3.2.1 Bit Packing Concept
JTLS-GO extensively uses bit-packing. When JTLS started in 1983, there were no 64-bitarchitecture computers. In fact, JTLS started development using one of the few advanced 32-bitarchitecture machines called the VAX Virtual Memory System (VAX/VMS).
In a 32-bit architecture, a computer word uses 32 bits or series of ones and zeros to hold data.Without getting into too much of a technical discussion, every integer variable held by a computerprogram is stored in a 32-bit word. The more words used to store program data, implies that thecomputer program needs a larger computer to execute. Table 1 depicts an example Simscript 32-bit computer word that is holding the number 5.
The number 5 is determined by the following equation:
Table 1. Example 32-Bit Computer Word
BIT NUMBER
32
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9 8 7 6 5 4 3 2 1
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
25 May 2020 28 JTLS-GO 6.0.0.0
Design Plan JTLS-2013-11707 ROLANDS & ASSOCIATES Corporation
For the Table 1, this would expand to the following equations:
Within JTLS there are several integer variables, that do not require a full 32-bits to hold the valueof the data element. For example, the Directed Search Area (DSA) entity has a flag, DSA ONCEONLY FLAG, indicating whether the owning side should only collect on the DSA once. As a flag,this variable can have only two possible values, zero which in JTLS-GO means No, and one whichmeans Yes. If this attribute was held by itself in a full integer word, only one bit of the 32-bit wordwould be used. The other 31-bits would always be empty.
For this reason, previous versions of JTLS-GO used the concept of bit-packing, where thevariables are defined to be held in specific bits of a 32-bit word. Continuing with the DSAexample, one DSA attribute word was bit packed as shown in Table 2. Bit 27, highlighted in“Yellow” held the single DSA ONCE ONLY FLAG.
Table 2. Example DSA Packed Word
DSA ATTRIBUTES PACKED INTO SINGLE WORD
UNUSEDUSE
FLAG
AREA
TYPEFORCE SIDE PRIORITY
32
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9 8 7 6 5 4 3 2 1
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
DecimalNumber BitValue 2bit 1–bit 1=
32
=
DecimalValue 1 23 1– 0 22 1– 1 21 1– + +=
DecimalValue 1 22 0 21 1 20 + +=
DecimalValue 1 4 0 2 1 1 + +=
DecimalValue 4 0 1+ + 5= =
JTLS-GO 6.0.0.0 29 25 May 2020
ROLANDS & ASSOCIATES Corporation Design Plan JTLS-2013-11707
If bit packing was not used, each DSA within th model, would have required five full words to holdthe exact same data.
Simscript III has deprecated this bit packing. The Design Team was initially worried that theamount of memory would increase drastically once bit packing was removed. Our evaluationproved that this was not much of a problem, for the following reasons:
• When CACI moved Simscript to the 64-bit architecture, a full integer word went fromtaking up 32 bits of computer memory to 64-bits of computer memory, but the computerlanguage did not allow programmers to bit back bits 33 through 64. This means thatTable 2 is really 64 bits long, and there are actually 37 bits of unused space.
• The integer variable size definitions were expanded. An integer variable can be defined asshown in Table 3
Continue to consider the example for the DSA. In JTLS-GO 5.1, each DSA took up 64 bits to hold,the five attributes described in Table 2. During the conversion as a result of this ECP, thesespecific attributes were defined as shown in Table 4 and will take up a total of 80 bits. This is notevent close to the expected five-fold increase in memory requirements. The end result isapproximately only a 25% increase.
Table 3. Available Integer Variable Sizes
VARIABLE DEFINITION WORD SIZE
INTEGER2 16 Bits (0 to 65535)
SIGNED INTEGER2 16 Bits (-32768 to 32767)
INTEGER4 32 Bits
SIGNED INTEGER4 32 Bits
INTEGER 64 Bits
Table 4. Non-Packed DSA Attribute Example
VARIABLE SIZE
DSA PRIORITY INTEGER2 - 16 Bits
DSA FORCE SIDE INTEGER2 - 16 Bits
DSA AREA TYPE INTEGER2 - 16 Bits
DSA USE FLAG INTEGER2 - 16 Bits
DSA ONCE ONLY FLAG INTEGER2 - 16 Bits
Total 80 Bits
25 May 2020 30 JTLS-GO 6.0.0.0
Design Plan JTLS-2013-11707 ROLANDS & ASSOCIATES Corporation
Now this is only one entity and one packed variable, but the concept is similar for other packedvariables. There will definitely be an increase in the amount of memory needed for JTLS-GO, butthe additional memory is believed to be within the acceptable range.
Every integer variable has been analyzed and has been placed in the smallest acceptable integersize definition to save as much memory as possible.
3.2.2 Ground Unit Number Hours Moved Per Day
There was one integer variable that used bit packing which needed to be converted to SimscriptIII is a completely different manner. This integer Unit attribute was called UT MOVE RECORD andit contains 24 individually accessed bit to represent if the unit has moved in the previous 24 hourperiod. This variable was used to determine if a Unit had moved more than its daily allowedmovement time.
Placing this data is separate variables would have increased the computation time needed todetermine the unit’s used movement time within the last 24 hours. Instead the variable waschanged to a bit mask and already existing code within JTLS-GO was used to set specific wordbits. Each hour that a unit moves, a single bit is set. During the HOURLY UNIT PROCESSING Eventthe bits are moved one bit to the left. dropping off the bit that represented whether the unit hadmove 24 hours ago.
Using this mask strategy, it is very easy to determine whether a unit needs to stop to temporarilyrest because it has moved more than the database specified limit for the unit held in the variableTUP MAX MOVE HOURS PER DAY. Understanding the actual computer programmingimplementation is not necessary, but since it is special code, special testing is required.
3.3 Variable Equivalence
Variable equivalencing is another memory saving capability that is used within JTLS-GO.
3.4 Permanent Entities
4.0 Data Changes
No data changes are required for this ECP.
5.0 Order Changes
No Order changes were required for this ECP.
JTLS-GO 6.0.0.0 31 25 May 2020
ROLANDS & ASSOCIATES Corporation Design Plan JTLS-2013-11707
6.0 JODA Changes
No JODA changes were required for this ECP.
7.0 Test Plan
No model capability changes were made as part of this ECP. This means that all of the testsprovided in this section are considered regression tests. It would help if the tester was familiarwith previous versions of JTLS-GO to insure the regression test provides similar results.
7.1 Force Unit To Rest
Purpose: Order a Unit to conduct a move that will take longer than its assignedMAX.MOVE.HOURS.PER.DAY to complete.
Step 1: Using a Controller WHIP, right-click on a ground Unit on the Map Component or theCommand Hierarchy, and select the “Unit Info” option. Make sure the “PrototypeName” data filter is toggled. Note the name of the Unit’s Tactical Unit Prototype (TUP).
Step 2: Open the SET.TACTICAL.UNIT.PROTO Order from the Orders > Game Control >Parameters > Unit Prototype Parameters menus. Choose the TUP that matches theTUP of the selected Unit. Select the “Show” tab. Select the “BASICS” radial button.Send the order.
Step 3: Open the Message Browser and view the message sent detailing the TUP. View theUnit’s MAX.MOVE.HOURS.PER.DAY, listed as “The Maximum Amount of Time that UnitCan Move in Any 24-Hour Period.”
Step 4: Set game speed to anything greater than 0. To do so in the JODA Console, run thecommand “o <desired speed>”.
Step 5: Send a Move order to the selected Unit in which the distance it must travel requiresthe Unit to move for longer than its MAX.MOVE.HOURS.PER.DAY.
Expected Results: The Unit has been forced to rest; the Unit will have a mission of “moving”but a posture of “defend” once it has exceeded its MAX.MOVE.HOURS.PER.DAY.
7.2 Force Unit To Rest After Changing MAX.MOVE.HOURS.PER.DAY
Purpose: Change a unit's MAX.MOVE.HOURS.PER.DAY, then have a unit conduct a move that willtake longer than its assigned MAX.MOVE.HOURS.PER.DAY to complete.
25 May 2020 32 JTLS-GO 6.0.0.0
Design Plan JTLS-2013-11707 ROLANDS & ASSOCIATES Corporation
Step 1: Using a Controller WHIP, right-click on a ground Unit on the Map Component or theCommand Hierarchy, and select the “Unit Info” option. Make sure the “PrototypeName” data filter is toggled. Note the name of the Unit’s Tactical Unit Prototype (TUP).
Step 2: Open the SET.TACTICAL.UNIT.PROTO Order from the Orders > Game Control >Parameters > Unit Prototype Parameters menus. Choose the TUP that matches theTUP of the selected Unit. Select the “Basics” tab. Enter a value in the “MaximumMove Hours” field. Select the “Show” tab. Select the “BASICS” radial button. Send theorder.
Step 3: Open the Message Browser and view the message sent detailing the TUP. View theUnit’s MAX.MOVE.HOURS.PER.DAY, listed as “The Maximum Amount of Time that UnitCan Move in Any 24-Hour Period.”
Step 4: Set game speed to anything greater than 0. To do so in the JODA Console, run thecommand “o g <desired speed>”.
Step 5: Send a Move order to the selected Unit in which the distance it must travel requiresthe Unit to move for longer than its MAX.MOVE.HOURS.PER.DAY.
Expected Results: The Unit has been forced to rest; the Unit will have a mission of “moving”but a posture of “defend” once it has exceeded its MAX.MOVE.HOURS.PER.DAY.
7.3 Force Unit To Rest After Several Moves
Purpose: Force a Unit to rest when assigned a new move task, if it has already reached itsMAX.MOVE.HOURS.PER.DAY. Without changing its MAX.MOVE.HOURS.PER.DAY, have aunit conduct several moves with breaks in between until it has reached its totalMAX.MOVE.HOURS.PER.DAY.
Step 1: Using a Controller WHIP, right-click on a ground Unit on the Map Component or theCommand Hierarchy, and select the “Unit Info” option. Make sure the “PrototypeName” data filter is toggled. Note the name of the Unit’s Tactical Unit Prototype (TUP).
Step 2: Open the SET.TACTICAL.UNIT.PROTO Order from the Orders > Game Control >Parameters > Unit Prototype Parameters menus. Choose the TUP that matches theTUP of the selected Unit. Select the “Show” tab. Select the “BASICS” radial button.Send the order.
Step 3: Open the Message Browser and view the message sent detailing the TUP. View theUnit’s MAX.MOVE.HOURS.PER.DAY, listed as “The Maximum Amount of Time that UnitCan Move in Any 24-Hour Period.”
JTLS-GO 6.0.0.0 33 25 May 2020
ROLANDS & ASSOCIATES Corporation Design Plan JTLS-2013-11707
Step 4: Set game speed to anything greater than 0. To do so in the JODA Console, run thecommand “o <desired speed>”.
Step 5: Send a Move order to the selected Unit in which the distance it must travel does notrequire the Unit to move for longer than its MAX.MOVE.HOURS.PER.DAY.
Step 6: Repeat Step 5 until the unit has moved as many hours as itsMAX.MOVE.HOURS.PER.DAY.
Expected Results: The Unit has been forced to rest and will not move if it has reached itsMAX.MOVE.HOURS.PER.DAY. A message will be sent explaining that the Unit cannot moveuntil it has rested the appropriate amount of hours.
7.4 Force Unit To Rest After Several Moves With Altered MAX.MOVE.HOURS.PER.DAY
Purpose: Force a Unit to rest when assigned a new move task, if it has already reached itsMAX.MOVE.HOURS.PER.DAY. After changing its MAX.MOVE.HOURS.PER.DAY, have aunit conduct several moves until it has reached its total MAX.MOVE.HOURS.PER.DAY.
Step 1: Using a Controller WHIP, right-click on a ground Unit on the Map Component or theCommand Hierarchy, and select the “Unit Info” option. Make sure the “PrototypeName” data filter is toggled. Note the name of the Unit’s Tactical Unit Prototype (TUP).
Step 2: Open the SET.TACTICAL.UNIT.PROTO Order from the Orders > Game Control >Parameters > Unit Prototype Parameters menus. Choose the TUP that matches theTUP of the selected Unit. Select the “Basics” tab. Enter a value in the “MaximumMove Hours” field. Select the “Show” tab. Select the “BASICS” radial button. Send theorder.
Step 3: Open the Message Browser and view the message sent detailing the TUP. View theUnit’s MAX.MOVE.HOURS.PER.DAY, listed as “The Maximum Amount of Time that UnitCan Move in Any 24-Hour Period.”
Step 4: Set game speed to anything greater than 0. To do so in the JODA Console, run thecommand “o <desired speed>”.
Step 5: Send a Move order to the selected Unit in which the distance it must travel does notrequire the Unit to move for longer than its MAX.MOVE.HOURS.PER.DAY.
Step 6: Repeat Step 5 until the Unit has moved as many hours as itsMAX.MOVE.HOURS.PER.DAY.
25 May 2020 34 JTLS-GO 6.0.0.0
Design Plan JTLS-2013-11707 ROLANDS & ASSOCIATES Corporation
Expected Results: The Unit has been forced to rest and will not move if it has reached itsMAX.MOVE.HOURS.PER.DAY. A message will be sent explaining that the Unit cannot moveuntil it has rested the appropriate amount of hours.
7.5 Unit Start And Stop Rest Time During Checkpoint
Purpose: Take a checkpoint while a Unit is moving to make sure that the Unit will begin resting atthe same time once the game has been restarted.
Step 1: Using a Player WHIP, send a Move order to a ground Unit.
Step 2: While the Unit is moving, take a running checkpoint.
Step 3: Continue running the game and take note of what time the Unit stops moving.
Step 4: Restart the game from the checkpoint and run forward.
Expected Results: The Unit should stop moving at the same time as before the game restart.
7.6 Unit Resumes Moving After Checkpoint
Purpose: Take a checkpoint while a unit is resting to make sure that the unit will begin moving atthe same time once the game has been restarted.
Step 1: Using a Player WHIP, send a Move order to a ground Unit.
Step 2: Once the Unit is resting, take a running checkpoint.
Step 3: Continue running the game and take note of what time the Unit stops resting.
Step 4: Restart the game from the checkpoint and run forward.
Expected Results: The Unit should stop resting at the same time as before the game restart.
7.7 Verify Unit Rest Time
Purpose: Verify that the amount of time for a Unit to resume movement displayed in theMessage Browser matches the time that a Unit will end its resting task in the Unittasking window.
Step 1: Using a Player WHIP, send a Move order to a Unit that will run long enough to put theunit into rest.
Step 2: Once the Unit is resting, send the Unit a new Move order.
JTLS-GO 6.0.0.0 35 25 May 2020
ROLANDS & ASSOCIATES Corporation Design Plan JTLS-2013-11707
Expected Results: The Message Browser should display the same amount of time for the Unitto resume movement as time that the Unit will end its resting task in the Unit tasking window.
7.8 Controller Order Tests
Purpose: The purpose of this test is to ensure that all of the Controller Orders work properly.
Step 1: Table 5 lists all of the available controller orders. Not all orders are listed becauseseveral of existing Controller Orders are covered in different test plans that are a partof JTLS-GO Version 6.0.
Table 5. Controller Order Checklist
CHECK
BOXORDER
25 May 2020 36 JTLS-GO 6.0.0.0
Design Plan JTLS-2013-11707 ROLANDS & ASSOCIATES Corporation
Table 5. Controller Order Checklist
CHECK
BOXORDER
JTLS-GO 6.0.0.0 37 25 May 2020
ROLANDS & ASSOCIATES Corporation Design Plan JTLS-2013-11707
Table 5. Controller Order Checklist
CHECK
BOXORDER
25 May 2020 38 JTLS-GO 6.0.0.0
Design Plan JTLS-2013-11707 ROLANDS & ASSOCIATES Corporation
Table 5. Controller Order Checklist
CHECK
BOXORDER
JTLS-GO 6.0.0.0 39 25 May 2020
ROLANDS & ASSOCIATES Corporation Design Plan JTLS-2013-11707
Table 5. Controller Order Checklist
CHECK
BOXORDER
25 May 2020 40 JTLS-GO 6.0.0.0
Design Plan JTLS-2013-11707 ROLANDS & ASSOCIATES Corporation
Expected Results: All orders should execute and operate as expected.
7.9 Player Order Tests
Purpose: The purpose of this test is to ensure that all Player Orders work properly.
Step 1: Table 6 lists all of the available player orders. Not all orders are listed becauseseveral of existing Player Orders are covered in different test plans that are a part ofJTLS-GO Version 6.0.
Table 6. Player Order Checklist
CHECK
BOXORDER
Table 5. Controller Order Checklist
CHECK
BOXORDER
JTLS-GO 6.0.0.0 41 25 May 2020
ROLANDS & ASSOCIATES Corporation Design Plan JTLS-2013-11707
Table 6. Player Order Checklist
CHECK
BOXORDER
25 May 2020 42 JTLS-GO 6.0.0.0
Design Plan JTLS-2013-11707 ROLANDS & ASSOCIATES Corporation
Table 6. Player Order Checklist
CHECK
BOXORDER
JTLS-GO 6.0.0.0 43 25 May 2020
ROLANDS & ASSOCIATES Corporation Design Plan JTLS-2013-11707
Table 6. Player Order Checklist
CHECK
BOXORDER
25 May 2020 44 JTLS-GO 6.0.0.0
Design Plan JTLS-2013-11707 ROLANDS & ASSOCIATES Corporation
Table 6. Player Order Checklist
CHECK
BOXORDER
JTLS-GO 6.0.0.0 45 25 May 2020
ROLANDS & ASSOCIATES Corporation Design Plan JTLS-2013-11707
Table 6. Player Order Checklist
CHECK
BOXORDER
25 May 2020 46 JTLS-GO 6.0.0.0
Design Plan JTLS-2013-11707 ROLANDS & ASSOCIATES Corporation
Expected Results: All orders should execute and operate as expected.
Table 6. Player Order Checklist
CHECK
BOXORDER
JTLS-GO 6.0.0.0 47 25 May 2020
ROLANDS & ASSOCIATES Corporation Design Plan JTLS-2013-11707
25 May 2020 48 JTLS-GO 6.0.0.0
Related Documents
