|
Please wait ......
AICC CMI/Lesson Communication - Overview
Terms of use
X
Terms of use
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 Initiative
|
The Aviation Industry CBT Committee (AICC) defines, on its CMI Guidelines for Interoperability technical report, a common way to start learning contents (CBTs), a common mechanism for learning contents to communicate with an CMI (Computer Managed Instruction) system, and a predefined data model or vocabulary as the basis for the communication.
These three aspects are considered inside runtime environments. The purpose of these specifications is to allow a single CMI system to initiate and use lessons developed from different CBT vendors.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
The common way for starting learning contents is the Launch Mechanism. This mechanism defines the procedures and responsibilities for the communication establishment between the delivered content and the CMI System. Once this communication is started, there must be a clearly defined procedure to exchange information. The communication between CMI and lessons (or Asignable Units) is supplied by an Communication Interface that standardizes communication protocols by providing methods for the runtime environment to get informed about the lesson state (initialized, finished, etc.), and for getting and setting data between the CMI and the lesson. The common vocabulary is the Data Model, which defines a standard list of elements used to characterize the information being communicated, such as the state of the learning content. |
CMI/Lesson data flow
|
|
Launch Mechanism
The AICC CMI committee defines possible methodologies for the initiation of a CBT system from a non-native CMI system. Note these are possible methods but others do exist. CMI developers are encouraged to use the method that is most efficient for their systems.
CMI system developers must establish a mechanism to launch multiple CBT vendor runtime systems. This mechanism will be different in the DOS and Windows environment; however, two requirements will be the same. They are:- Students must have a single point of entry into and exit from the CMI -> CBT -> CMI run sequence. CMI developers must insure that the CBT application is well-behaved, meaning that CBT results get reported back to CMI system for current assignment (i.e. CMI initiates CBT, CBT runs, CBT returns to CMI with results of lesson).
- The CMI system may allow multiple lessons to run concurrently. However, once the lesson is begun, it is mandatory that the lesson returns its results to the CMI system when it finishes.
|
| For browser and Web-based content, the CMI (or LMS) shall launch the content from a browser window that contains the communication API implementation (see below), or must provide a parent frame that contains the API implementation. This window shall contain a reference to the assignable unit which is a URL. |
Communication Interface
CMI/Lesson communication mechanism have evolved through several stages along the years. Initially, when computer based educational systems used to be autonomous, AICC defined a communication interface based on files on top of the MS-DOS/Windows operating system. Then, this time in collaboration with the ADL initiative, a communication interface based on the HTTP protocol substituted the former. This new interface was clearly devised for TCP/IP networks. Finally, this model was further refined to propose an Application Program Interface (API) to separate the runtime environment from the protocol layers.
API-based communication interface
|
|
The set of API function calls consists of the following:- LMSInitialize("")
- LMSFinish("")
- LMSGetValue(cmi.group.element)
- LMSSetValue(cmi.group.element, value)
- LMSCommit("")
- LMSGetLastError("")
- LMSGetErrorString(errornumber)
- LMSGetDiagnostic(parameter)
|
Data Model
For the old MS-DOS based communication mechanism, the AICC defined the format of two files (one for each communication way). The first file is to be created by the CMI system, and the second is to be created by the lesson.
These files were finally mapped to a Data Model that defines the data elements that can be used in the specified communication API. |
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: 3.5 release 2
Release Date: 2 April 2001
Status: Final
Editor: Jack Hyde (Chairman CMI Subcommittee)
Electronic Version: Online available (PDF) |
Tracking of changes
The main purpose of this revision is to make the AICC API match the ADL SCORM version 1.1. The two changes necessary are to make the function calls all return a true false if not returning data, and to add an new data element called comments_from_lms. The other changes are corrections or amplifications.- Sec 5.1.1 - Correct to say lesson_status must have a flag when appropriate. (No flag has meaning too. No flag means normal re-entry.)
- Appendix A.4 - Corrected table and example to show “http://” is required in URL.
- Appendix B.3.2 - Added return value to data elements that previously did not have one.
- Appendix B.3.4 - Corected parameter and added return value.
- Appendix B.3.6 - Added return value of CMIBoolean.
- Appendix B.3.7 - Added return value of CMIBoolean.
- Appendix B.3.8 - Corected parameter (from none to empty string).
- Appendix B.4 - Added comment_from_lms data element. Changed objectives.n.scores to objectives.n.score (single value to match SCORM.) Changed objectives.n.statuses to objectives.n.status (single value)
- Appendix B.5 - Changed objectives.n.scores to objectives.n.score (single value to match SCORM). Changed objectives.n.statuses to objectives.n.status (single value).
- Appendix B.6 - Corrected interactions.n.id value data type to CMIIdentifier (from CMIString255). Corrected paths.n.location_id data type to CMIIdentifier.
- Appendix B.8 - Changed objectives.n.scores and statuses to score and status.
- Appendix B.9 - Changed interactions.id data type to CMIIdentifier. Changes objectives.scores and statuses to score and status. Changed paths.location_id data type to CMIIdentifier.
|
The first official release of the AICC CMI Guidelines for Interoperability 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).
|
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
CMI Guidelines For Interoperability (DRAFT version v4)
[28 February 2003] An effort was started last summer to rewrite/reorganize the now "famous" AICC Document, CMI001 - CMI Guidelines For Interoperability (a.k.a. the "CMI Spec").
A working draft of the new version (Which will be called "CMI001 version 4.0" when released) is now ready for an open review. The review period will last until June 2003. Note that the draft document is far from "done", new drafts will be issued during review period.
Download URL: http://aicc.org/review/cmi001v4WD9.zip
File Format: PK-Zipped, MS Word '97
File Size: 376K |
Purpose of the Revision
The pupose of this revision to CMI001 is "spec maintenance". The intention is not to change existing features but to ensure that CMI001 is interpreted in one way (Senso Unico). No new features are planned for this revision.
The goals of this revision are as follows:
Goal #1 - Disambiguate
Clarify Ambiguities
Narrow Definitions
Make explanations more concise
Fix Errors and Omissions
Resolve conflicting statements
Goal #2 - Clean house
Eliminate Duplication
Reorganize
Preserve existing features in use today and identify features for deprecation/removal |
|