|

Please wait ......
AICC Course Structure - Overview
Terms of use
X
Terms of use
Taken from the Aviation Industry CBT Committee (AICC) official Web site.
Print
Scope
Aviation Industry CBT Committee
|
The Aviation Industry CBT Committee (AICC) describes, as part of its CMI Guidelines for Interoperability technical report, a standardized course structure interchange mechanism. The purpose to define interfaces and rules that allow CBT (Computer-Based Training) Content from a variety of sources to interoperate with CMI (Computer Managed Instruction Systems).
This mechanism is based on the definition of the format of a set of standardized interchange files aimed to describe both the static structure of the course and the dynamic behavior (the progression logic philosophy for the whole instructional material of a course) intended by the course developers.
After moving a course, a review-and-modify effort is going to be required. The existence of these standard interchange files however, should eliminate a large number of the man-hours necessary to input a new course from scratch.
This document defines the following:- The mechanism used by the CMI to launch CBT content
- Common mechanisms and data for CMI/CBT communication
- A common definition for organization and sequencing of CBT content in a course.
CMI Guidelines For Interoperability |
Terms of use
X
These contents have been obtained from the AICC web site and edited for presentation. Please refer to the AICC web site for additional information on terms of use.
Print
Introduction
In the AICC Terminology, the parts of the course that can be rearranged to define the order in which a student can experience a course are referred to as structure elements. These are the Assignable Units (AU, also referred to as a lesson) and the Blocks (a block is simply a grouping of lessons and other blocks). The order in which these appear in the course defines its structure.
Another building block, which may be required to define prerequisites for a course, is the Objective (this is mostly content information, that includes a title for each objective, and a narrative description if desired).
These three items (Assignable Unit, Block and Objetive) are referred to as course elements. |
Example of a simple course structure
|
|
Standard Files
The AICC defines the format of seven files that can be used to describe a course's content and structure:- COURSE (CRS). This file contains information about the course as a whole. It offers information that relates to more than just a single element in the course. It includes (among others) data elements like the course creator, the course title, the total number of blocks, the total number of lessons or a textual description of the course.
- ASSIGNABLE UNIT (AU). It contains a table with information relating to the assignable units (AU) in the course. Each AU has its own record (or row in the table) and includes fiels like: Type, File Name, Mastery Score, Max Time Allowed, etc.
- DESCRIPTOR (DES). This file contains a complete list of every course element in the course. It is used as the basic cross reference file showing the correspondence of system generated IDs with user defined IDs for every element. This file also contains any textual description created for an element in the course.
- COURSE STRUCTURE (CST). This file contains the basic data on the structure of the course. It includes all of the assignable units and blocks in the course. The order in which these appear in the file implies (but does not force) an order for presentation to the student. Even though the student may have the option of selecting any assignable unit or block, the CMI router will probably list them in the order in which they appear in this file. If a specific order is required by the developer, that order is specified in the prerequisites file.
- OBJECTIVES RELATIONSHIPS (ORT). Objectives have complex and variable relationships to other elements of a course. For instance, a lesson may cover several objectives. A single objective may require mastery of several lessons. Other objectives may require the mastery of many sub-objectives. The Objectives Relationship file is able to define all of these relationships. However, not all CMI systems depend upon objectives for routing decisions. Not all objectives are critical to the functioning of a CMI system. This file is optional for course descriptions that do not have objectives as prerequisites for assigning lessons. All objectives that are part of a prerequisite are required in this file.
- PREREQUISITES (PRE). Sometimes it may be desirable to prevent a student from entering a lesson until he has met certain prerequisites. This file allows that sort of constraint to be placed on each block or assignable unit (AU) in a course.
- COMPLETION REQUIREMENTS (CMP). The Completion Requirements file is designed to allow the explicit specification of when an assignable unit, block or objective should be assigned a specific status (Passed, Completed, Failed, Incomplete, Brosed, Not Attempted) when that status does not conform to the defaults. It is essentially an exception file.
|
Levels of Complexity
The AICC guidelines define three levels of complexity in describing the course structure. Increasing the level of complexity from level 1 to 2 to 3 should result in: (a) Less effort to review and modify the CMI system after importing the data and (b) More complete description of the designer's intended usage of the course material.
The level of complexity determines the number of files required and the amount of information required in each file.- LEVEL 1. This is the simplest level. It describes the contents of the course (the lessons or assignable units). It also defines the course structure in terms of assignable units and blocks. It allows the construction of a course hierarchy. The order in which the student may go through the course is only implied with the structure. This description cannot force any order on the student. (Required Files: CSR, AU, DES, CST).
- LEVEL 2.This level of complexity adds a possible single prerequisite for each structure element (an assignable unit or a block). The status of each prerequisite is simple: complete or incomplete. The order in which the student moves through the course can be forced by prerequisites. This level also introduces the ability to identify a structural element whose completion status can affect another element. This concept enables (among other things) the use of separate assignable units as pretests. Thus the completion of one assignable unit (such as a pre-test) can result in the "Pass" status of another unit (such as an instructional lesson). (Required Files: CSR, AU, DES, CST, CMP, PRE).
- LEVEL 3. Level 3 is divided into two parts. A level 3 conforming system may support features described as Level 3A or Level 3B or both feature sets. Level 3A adds the ability to define complex prerequisites and complex completion requirements. Logical expressions may be used to describe these requirements. Level 3B describes the relationship of objectives to the course structural elements. Supporting 3A and 3B allows the use of complex prerequisites and completions with objectives. (Required Files 3A: CSR, AU, DES, CST, CMP, PRE; Required Files 3B: CSR, AU, DES, CST, ORT, CMP, PRE).
|
Terms of use
X
These contents have been obtained from the AICC web site and edited for presentation. Please refer to the AICC web site for additional information on terms of use.
Print
General Information
Title: AICC - CMI Guidelines for Interoperability
Version: 4.0
Release Date: 16 August 2004
Status: Final
Point of Contact: Scott Bergstrom (AICC Administrator)
Electronic Version: Online available (PDF) |
Tracking of changes
Complete rewrite and reorganization of all sections. See CMI001 version 3.5 for a complete revision history back to version 1.0. This revision is intended to be functionally equivalent to CMI001 version 3.5
Major changes include:- All definitions were narrowed and clarified.
- Conflicting rules and statements clarified/resolved.
- Structured notation was added for every data element to define data types, range of data, and data vocabularies.
- Communication and course structure data models separated from individual bindings (methods of implementation). All bindings were mapped to the data models in separate sections.
- The content of all appendices (Appendix A, and Appendix B) were merged into the main body of the document.
|
| The first official release of the document was approved in September, 1993 at the General Meeting of the AICC. Several versions of it were issued since that date. |
Terms of use
X
These contents have been obtained from the AICC web site and edited for presentation. Please refer to the AICC web site for additional information on terms of use.
Print
Advanced Distributed Learning (ADL) Initiative
- ADL and AICC are coordinating efforts through the IEEE/LTSC (Learning Technology Standards Committee).
- ADL & AICC are also collaborating on the development of comprehensive compliance testing procedures for CMI001 (AICC/CMI Guidelines for Interoperability).
|
IEEE P1484 - Learning Technology Standards Committee (LTSC)
- The AICC has formally submitted the AICC/CMI Guidelines for Interoperability (CMI001) to the IEEE/LTSC (Learning Technology Standards Committee) and is actively pursuing its adoption as an IEEE standard (P1494.11).
- The AICC has also proposed that the LTSC pursue the development of a CBT interchange language standard per AGR-007 (CBT Interchange Guidelines).
|
IMS Project
- IMS and AICC are coordinating efforts through the IEEE/ LTSC (Learning Technology Standards Committee).
- AICC plans to adopt IMS meta-data where practical in future releases of CMI001 (AICC/CMI Guidelines for Interoperability).
|
| Please visit the following web page to read the last news published in the AICC.AICC News Web Page |
Terms of use
X
These contents have been obtained from the AICC web site and edited for presentation. Please refer to the AICC web site for additional information on terms of use.
Print
AICC Meetings Information
The AICC meets three times per year. Two meetings are typically held in North America and one in Europe. The meeting locations are determined by the availability of meeting hosts. Typically an AICC member company will serve as a meeting host.AICC Meetings Web Page |
AICC Next Meeting
Date: January, 2009
Location: Mumbai, India - Hosted by Hurix. January, 2008 |
AICC Upcoming Meetings
- June 2009 - Boston, MA - Hosted by OutStart
- Septemer 2009 - Stuttgart.Germany (Tentative)
- January 2010 - Miami, Florida - Hosted by Alteon (Tentative)
|
|