NextGen FSM
NextGen FSM
Breadcrumbs

Understanding Crew Shell Integration with Gisware

Gisware, by its native design, doesn't inherently understand the Crew Shell entity as it exists in NextGen FSM. Therefore, the NextGen FSM layer acts as a necessary translator or intermediary. Its critical responsibility is to convert the Crew Shell entity into a format and data structure that Gisware can recognize and process, which allows Gisware to use its algorithms to solve scheduling problems.

Crew Shell Management in Virtual Scheduling

Crew Shells are primarily managed within FSM's Virtual Scheduling process, but their inclusion varies by phase:

  • Phase 1 - Processing Teams Creation Model: Crew Shells are actively managed according to their defined configurations. This is where the system recognizes and prepares Crew Shells for potential scheduling.

  • Phase 2 - Processing Separated Teams Phase: Crew Shells are not considered.

  • Phase 3 - Processing Final Assignment Model: Crew Shells are not integrated. The model configuration for this phase typically doesn't include an Integration Type that supports Crew Shells, and the system treats Crew Shells as indivisible units.

  • Phase 4 - Post-VRP Optimization: Crew Shells are optimized according to their configurations. After initial assignments, the system refines their routing and sequencing based on their properties.

Note: Crew Shells are not included in Real Time Scheduling. If individual resources are members of a Crew Shell, they are explicitly excluded from real-time re-elaboration with the reason The resource works in a crew shell.

Criteria for Crew Shell Inclusion in Virtual Scheduling

A Crew Shell is included in a virtual scheduling elaboration only if all of the following conditions are met:

  • It is explicitly selected in the scheduling model.

  • It has a calendar defined for at least one day within the scheduling period.

  • It has at least one day that isn't blocked within the scheduling period.

  • It has at least one day without real scheduling within the scheduling period, which means tht it's available for virtual assignment.

Technical Assumptions and Underlying Data Structure

For integration, each NextGen FSM Crew Shell record (ACREWSHELL table) is conceptually linked to a fictitious user (AUSER table) and, subsequently, to a working team (AWORKINGTEAM table). This fictitious user and working team are used as internal constructs to represent the Crew Shell for scheduling purposes in a way that aligns with Gisware's expectations.

  • Data Alignment: Information such as departure and arrival addresses, and movement type, are automatically synchronized and aligned between these related entities (Crew Shell, fictitious user, fictitious working team).

  • Query Example: To extract the AUSEID (fictitious user ID) and AWTEID (associated work team ID) for a given Crew Shell code and Operation Center code, use the following SQL query:

    SELECT ACSHID_AUSE AUSEID, AWTEID
FROM aworkingteam WT, ACREWSHELL cs, AUSER u
WHERE cs.ACSHID_AUSE = u.AUSEID
  AND u.AUSEIDSINGLETEAM_AWTE = wt.AWTEID
  AND cs.ACSHCODE = ? -- CODE of the crew shell (e.g., 'ALPHA2')
  AND cs.ACSHID_AOCE IN (SELECT aoceid FROM AOPERATIONCENTER WHERE aocecode = ?); -- CODE of the OC (e.g., 'OCENE')

Gisware Request Structure: The <team> Element

When NextGen FSM sends a request to Gisware for scheduling, each Crew Shell is represented by a <team> XML element.

<team name="T30615">
    <worker name="5273§W30615"/>
    <days dislocation="max" from="09/12/2024" skills="S1,S2,S5,^SX,^SX,^Z_T,^I_T,^TURNO,^T30615" to="10/12/2024">
        <location ll="46.0949745,13.229808" type="start"/>
        <location ll="45.909424,13.3057286" type="end"/>
        <location ll="46.002199250000004,13.2677683" type="pivot"/>
        <slot end="17.00" start="08.00"/>
        <lunch end="13.00" start="12.00"/>
    </days>
</team>

<team> Element Attributes

  • name attribute: This attribute is constructed with the prefix T followed by the ARSHID (Resource Shift ID) of the fictitious user associated with the Crew Shell for the specific scheduling day. To determine this ARSHID, query the ARESOURCESHIFT table:

    SELECT ARSHID
FROM ARESOURCESHIFT a
WHERE ARSHID_AUSE = ? -- ID of the fictitious crew shell (e.g., 5274)
  AND TRUNC(ARSHSTARTDATE) = TO_DATE(?, 'dd-mm-yyyy'); -- Calendar date (e.g., 09-12-2024)

The <worker> Tag

Within the <team> tag, a <worker> tag is always included.

  • Representation: This <worker> tag represents the fictitious resource associated with the Crew Shell, acting as a dummy resource. It's present even if the Crew Shell is empty. It never represents the actual Crew Shell members.

  • name attribute: The name attribute of the <worker> tag consists of two parts separated by the § character:

    • Left of §: The identifier of the dummy resource (for example, 5273). You can extract this AUSEID with a query on ACREWSHELL and AOPERATIONCENTER tables:

      SELECT ACSHID_AUSE AUSEID FROM ACREWSHELL cs
WHERE cs.ACSHCODE = ? -- CODE of the crew shell (e.g., 'ALPHA2')
  AND cs.ACSHID_AOCE IN (SELECT aoceid FROM AOPERATIONCENTER WHERE aocecode = ?); -- CODE of the OC (e.g., 'OCENE')

    • Right of §: The ARSHID (Resource Shift ID) for the specific day the Crew Shell is being scheduled (for example, W30615 for 09/12/2024). This ARSHID is the same as the one used in the <team> name attribute.

The <day> Tag

Each <team> tag can contain a set of <day> tags, where each <day> tag corresponds to a period (or a single day) with consistent attributes for scheduling. Key attributes of the <day> tag for Crew Shells include:

  • dislocation attribute: Always passed as dislocation="max". This attribute, typically related to distance calculation for multi-location teams (the combination of points with the greatest distance), has no practical impact on Crew Shell scheduling because the system treats a Crew Shell as a unique entity with its own defined addresses.

  • from attribute: Represents the starting date of the scheduled period (for example, 09/12/2024).

  • to attribute: Represents the ending date of the scheduled period to be scheduled (for example, 10/12/2024).

  • skills attribute: This is a crucial attribute, valued by combining the Crew Shell's real skills with dynamically generated "metaskills."

Skills and Metaskills

The skills attribute within the <day> tag provides Gisware with information about the Crew Shell's capabilities.

  • Real Skills: These are extracted directly from the Crew Shell's definition in FSM (for example, Electrician, Welder). Each skill is identified by its TSKIID key from the TSKILL table. Qualifications are currently not managed for Crew Shells in this integration.

    • To determine skills owned by a Crew Shell for a specific day, use a query like this:

      SELECT TSKIID
FROM ACREWSHELL cs, RCREWSHELLSKILL rcs, TSKILL s
WHERE cs.ACSHID = rcs.RCSSID_ACSH
  AND rcs.RCSSID_TSKI = s.TSKIID
  AND ARSHID_AUSE = ? -- ID of the fictitious crew shell (e.g., 5274)
  AND TRUNC(ARSHSTARTDATE) = TO_DATE(?, 'dd-mm-yyyy') -- Calendar date (e.g., 09-12-2024)
ORDER BY TSKIID;

  • Metaskills: These Nexten FSM-generated to convey specific properties or characteristics of the Crew Shell that need to match corresponding properties of an activity. Metaskills are identifiable by a ^ character prefix.

    • ^SX (repeated n times): Reflects the minimum cardinality (Crew Size) of the team. For example, if the minimum cardinality is two, ^SX-^SX is injected.

    • ^Z_T: Identifies that the Crew Shell can receive activities from any zone in the territory (future versions may support specific scheduling zones).

    • ^I_T: Identifies that the Crew Shell can receive activities assigned to any enterprise (future versions may support specific enterprises/contractors).

    • ^TURNO: Identifies that the Crew Shell can receive activities specifically designated for resources "on shift."

    • ^T<ObjectID>: Identifies that the Crew Shell can receive activities pre-assigned to it (where <ObjectID> is the ARSHID of the ARESOURCESHIFT table).

    • Multi-day tasks: Currently, multi-day task assignments to Crew Shells are not handled. The ^P metaskill is never assigned to Crew Shell teams but is assigned to other teams and workers for multi-day activities with a duration greater than a minimum daily time, effectively preventing multi-day activities from being assigned to Crew Shells.

Location, Slot, and Lunch Tags

Within each <day> tag, additional tags define geographical points and time intervals:

  • <location> tag: Represents relevant positions of the Crew Shell.

    • type attribute: Specifies the type of location (e.g., start for departure, end for arrival, pivot for a calculated central point).

    • ll attribute: Contains the latitude and longitude coordinates.

    • Pivot Address: The pivot address is always calculated as the midpoint between the departure and arrival addresses if they are different.

  • <slot> tag: Represents the Crew Shell's work shift interval for the day (e.g., start="08.00" end="17.00").

  • <lunch> tag: If applicable, represents the theoretical lunch break interval within the shift (e.g., start="12.00" end="13.00").

    • These time-related attributes are derived from the Crew Shell's calendar. The following query can extract shift and break times:

      SELECT ARSHSTARTDATE, ARSHENDDATE, ARSHBREAKSTART, ARSHBREAKEND
FROM ARESOURCESHIFT rs, ACREWSHELL cs
WHERE rs.ARSHID_AUSE = cs.ACSHID_AUSE
  AND cs.ACSHCODE = ? -- CODE of the fictitious crew shell (e.g., 'ALPHA2')
  AND cs.ACSHID_AOCE IN (SELECT aoceid FROM AOPERATIONCENTER WHERE aocecode = ?); -- CODE of the OC (e.g., 'OCENE')
  AND TRUNC(rs.ARSHSTARTDATE) = TO_DATE(?, 'dd-mm-yyyy'); -- Calendar date (e.g., 09-12-2024)

Integration Logging

Scheduling logs track operations involving Crew Shells:

  • Involved Crew Shells: Crew Shells are managed as team/resource entities in the logs. The fictitious user and fictitious working team associated with the Crew Shell are included and searchable by their IDs in the existing logs.

  • Exclusion Reasons: Individual resources who are members of a Crew Shell are excluded from certain scheduling processes (for example, real-time scheduling) with a specific message like "Excluded because foreman… is a member of crew shell…"

Recap and Further Exploration

Understanding the integration of Crew Shells with Gisware reveals the complex translation and data mapping that occurs behind the scenes to leverage Gisware's scheduling capabilities. This conceptual understanding is vital for interpreting scheduling outcomes and for any custom development or troubleshooting related to Crew Shells in a Gisware-integrated FSM environment.

To further your understanding of related concepts: