Epic2 Electronic Checklists
Introduction
The Epic2 supports an electronic checklist feature that allows checklists to be viewed and completed within the avionics. Using this feature, the user can view checklists on the lower MFD. The user can also check off individual items in checklists and the system will track which items and checklists have been completed.
The Epic2 also allows for abnormal checklists to be linked to CAS items - in the event that a CAS alert is fired and a checklist is linked to that alert, the Abnormal Queue checklist page will be available.
In comparison to the G3000 checklists, the Epic2 checklists are rather dumb. There is no support for branching, links, or indentation.
By default, the electronic checklists feature is disabled in the Epic2. In order to enable the feature in an airplane installation, there are two things that must be done:
- Create an XML file that configures the checklists that are supported by the installation. For more information, see the next section.
- Point the Epic2 to the checklists XML file using the
<Checklist>panel.xmltag.
Creating a Checklist XML File
Checklists are configured using an XML file. The XML file defines the checklists included in the installation, how they are organized, and the contents of each checklist.
The checklist XML file must be placed within the coui://html_ui/ directory or one of its subdirectories. If the file is placed in another directory, the Epic2 will not be able to access it.
It is best practice to place the checklist XML file in an aircraft-specific directory, for example:
coui://html_ui/Airplanes/My_Airplane/checklist.xml
This greatly reduces the risk of file conflicts within the sim's virtual file system.
The Root <Checklist> Tag
Like all XML files, the checklist XML file must contain a single root tag. This tag must be named <Checklist>. All other tags in the file are placed within the root <Checklist> tag.
Groups
Checklists are organized into groups. Each group contains one or more checklists. In the checklist page each group has its own associated tab and the user can browse checklists in different groups by selecting different tabs.
Groups are defined in the XML file with <Group> tags placed directly under the root <Checklist> tag:
<Checklist>
<Group name="Normal">
</Group>
<Group name="Abnormal">
</Group>
<Group name="Emergency">
</Group>
</Checklist>
The order of the <Group> tags determines the order in which their tabs appear in the Checklist page. The Epic2 supports only the above-defined groups.
The name of each group will be displayed at the top of the Checklist page when a list from that group is selected. Additionally, the GTC Checklist page uses each group's name to label its corresponding tab by default (image, bottom).
Lists
Lists represent individual checklists. Each list belongs to a checklist group and contains one or more checklist items. Unlike the G3000, branches are not supported by the Epic 2. The user can select and display one list at a time in the Checklist page.
Lists are defined in the XML file with <List> tags placed directly under the <Group> tags of their parent groups:
<Checklist>
<Group name="Normal">
<List name="Before Engine Start">
</List>
<List name="Engine Start">
</List>
</Group>
</Checklist>
The order of the <List> tags within a <Group> tag determines the order of the corresponding lists in the group. The name of each list will be displayed at the top of the Checklist page when the list is selected, and also appears in the checklist pane when the user is browsing through checklists.
Linking a list to a CAS message
Lists can also be linked to a CAS message in the Epic2. When a CAS message is active, and a linked checklist exists, the Abnormal Queue button will become available on the checklist pane. When the Abnormal Queue page is selected, the checklists will be coloured based on the severity of the CAS message.
To link a checklist to a CAS message, use a <LinkedCasMessages> tag, with child <Message> tags. The contents of the message tags should be the names of the linked CAS messages.
Example:
<List name="Fuel Level Low">
<LinkedCasMessages>
<Message>FUEL LEVEL LOW L</Message>
<Message>FUEL LEVEL LOW R</Message>
<Message>FUEL LEVEL LOW L-R</Message>
</LinkedCasMessages>
<Item type="title">
<Text>
3A-FUEL-06
</Text>
</Item>
</List>
Items
Checklist items represent the "content" of checklists. There are four different types of items:
| Type | Description |
|---|---|
| Actionable | A selectable item describing a checklist step that can be completed. |
| Note | A non-selectable item that provides informational content. Cannot be completed. |
| Title | A non-selectable item that represents a section title. |
| Spacer | A non-selectable item that inserts an empty line into the rendered version of the checklist. |
Selectable items can be selected by users as they scroll through a list and will be highlighted with a cyan border when selected. Non-selectable items cannot be selected - they are skipped when the user scrolls through the list.
Actionable items have a completion state. The user can toggle the completion state of actionable items from not completed to completed and vice versa. When an actionable item is completed, it is rendered in lime and a green checkmark appears beside it.
A list must contain at least one item, but there is no minimum requirement for any specific type of item. Nonetheless, it is recommended that a list contain at least one selectable item.
Items are defined in the XML file using <Item> tags placed directly under the <List> tags of their parent lists. The order of the <Item> tags within their parent tag determines the order of the corresponding items in the list.
Defining Actionable Items
To define an actionable item, use an <Item> tag with a type attribute of actionable:
<Item type="actionable">
<LabelText>
1. Preflight Inspection
</LabelText>
<ActionText>
COMPLETED
</ActionText>
</Item>
The <LabelText> child tag is required and defines the text that describes the item's topic. The <ActionText> child tag is required and defines the text that describes the action to be taken for the item. The action text is rendered to the right of the label text, and the label and action texts are connected with a string of dots.
Defining Note Or Title Items
To define a note item, use an <Item> tag with a type attribute of note or title:
<Item type="note">
<Text>
Following engine start, a warm engine should run at idle thrust for at least 2 minutes prior to takeoff.
</Text>
</Item>
The <Text> child tag is required and defines the text that is rendered for the item.
Defining Spacer Items
To define a spacer item, use an <Item> tag with a type attribute of spacer:
<Item type="spacer" />
A spacer item's height (not including the padding and margin applied to all items) is equal to the line height of an actionable or note item.
Text Formatting
All standard text formatting conventions for XML files must be respected when creating the checklist XML file. In particular, this means that certain characters must always be escaped when they appear in the text content for a tag:
<(less than): escaped with<&(ampersand): escaped with&
Text rendered for all item types are formatted to automatically wrap to new lines when necessary while preserving whitespace characters (including newline characters). Text parsed from the various text tags in the XML file preserves all whitespace characters (including newline characters) except leading and trailing whitespace, which are entirely removed. Enclosing the text in quotes (either single or double) causes the text within the quotes to be parsed as a JSON-formatted string (after any XML-escaped characters are resolved).
To preserve leading and/or trailing whitespace in a text tag, use a JSON-formatted string:
<Text>
" The spaces before and after this sentence will be preserved. "
</Text>
To insert a forced line break, use a JSON-formatted string with an escaped newline character (\n):
<Text>
"This text will have a line break...\nafter the ellipsis."
</Text>
To prevent text from automatically wrapping to a new line at a specific space character, use the non-breaking space character instead. The non-breaking space character can be used directly in XML without escaping. However, it is recommended to escape the character (with  ) to make it obvious where non-breaking spaces are used:
<Text>
This text will not automatically wrap... after the ellipsis.
</Text>