ADL SCORM Run-Time Environment - Overview

Terms of use
X Terms of use
These contents have been obtained from the ADL web site and edited for presentation. Please refer to the ADL web site for additional information on terms of use.
Print
Image for 'Overview'
Advanced Distributed Learning Initiative
The Sharable Content Object Reference Model (SCORM), developed by the ADL initiative, includes the SCORM Run-time Environment (SCORM-RTE) specification.

The purpose of the SCORM Run-time Environment is to provide a means for interoperability between Sharable Content Object-based learning content and Learning Management Systems. A requirement of the SCORM is that learning content be interoperable across multiple LMSs regardless of the tools used to create the content. For this to be possible, there must be a common way to start content, a common way for content to communicate with an LMS and predefined data elements that are exchanged between an LMS and content during its execution. The three components of the SCORM Run-Time Environment are defined in the SCORM as Launch/Management, Application Program Interface (API) and Data Model.

Notes:
  1. ADL collaborated with AICC members and participants to develop a common Launch and API specification and to adopt the AICC Data Model for Web-based data elements.
  2. Currently, the ADL SCORM-RTE specification is endorsed by the "International Organization for Standardization" under the Technical Report ISO/IEC TR 29163-3:2009.
SCORM 2004 4th Edition
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the ADL web site and edited for presentation. Please refer to the ADL web site for additional information on terms of use.
Print
There are several key concepts that are introduced in the SCORM Run-Time Environment (RTE) book. The book covers the essential LMS responsibilities for sequencing content objects (SCOs or Assets) during run-time and allowing SCOs to indicate navigation requests. In addition, guidance is offered for providing navigation controls to learners. General subjects discussed include:
  • Run-Time Environment Management: Launching of content objects – SCOs and Assets, Management of communications with a SCO, Run-time environment data model management.
  • Application Programming Interface (API): LMS API requirements, SCOM communication requirements, communication error conditions) Run-Time.
  • Environment Data Model: Data model management and behavior requirements, Data type requirements.
Image for 'Introduction'
SCORM Conceptual Run-Time Environment.
Managing The Run-Time Environment
As described in the Content Aggregation Model, the SCORM Content Model is made up of three components:
  • Assets
  • SCOs
  • Content Organizations
The SCORM CAM describes the characteristics of launchable content objects; SCOs and Assets are the defined content model components that can be launched. Different launching requirements exist depending on the content object’s type. The launching process defines the common way for LMSs to launch content objects to the learner’s Web browser. The procedures and responsibilities for establishing communication between the launched content object and the LMS vary depending on the type of the launched content object.

It is the responsibility of the LMS to manage the sequencing between learning activities based on well-defined behaviors and the evaluation of defined sequencing information applied to activities. The progression through learning activities that comprise a particular learning experience may be sequential, nonsequential, user-directed or adaptive, depending on the sequencing information defined and the interactions between a learner and content objects.

The two SCORM Content Model components that can be launched by an LMS are Assets and SCOs. There are different launching requirements depending on the type of learning resource being launched. The launching mechanism defines the common way for LMSs to start learning resources. The procedures and responsibilities for the establishment of communication between the delivered learning resource and the LMS vary depending on the type of SCORM learning resource being launched:
  • Asset. For content objects that represent Assets, the SCORM launch model only requires that an LMS launch the Asset using the HTTP protocol. An Asset does not communicate to the LMS via the API and Data Model.
  • Sharable Content Object (SCO). For content objects that represent SCOs, the SCORM launch model requires that an LMS launch and track one SCO at a time (per learner). In other words, the LMS launches and tracks one SCO at a time (per learner).The launched SCO can itself implement an API Instance for subordinate SCOs that it may launch and track. The LMS is not responsible for “knowing” of these subordinate SCOs. If this is the case, the SCO that was launched by the LMS is responsible for all cleanup (e.g., closing of any windows that were opened to host the subordinate SCO) upon termination of itself. All communication with the LMS must take place with the SCO that was launched by the LMS.
Application Program Interface (API)
The use of a common API fulfills many of the SCORM’s high-level requirements for interoperability and reuse. It provides a standardized way for SCOs to communicate with LMSs, yet it shields the particular communication implementation from the SCO developer. How the LMS-provided API Instance communicates with the server-side component of the LMS is outside the scope of SCORM. This back-channel communication can be implemented anyway the LMS vendor likes.
There are several terms that are used throughout SCORM: API, API Implementation and API Instance. The figure shown below describes the terms and their relationships to each other.
Image for 'Application Program Interface (API)'
API, API Instance, API Implementation
In its simplest terms, the API is merely a set of defined functions that the SCO can rely on being available.

An API Implementation is a piece of functional software that implements and exposes the functions of the API. How an API Implementation functions should not matter to a SCO developer, as long as the API Implementation uses the same public interface and adheres to the semantics of the interface. The LMS need only provide an API Implementation that implements the functionality of the API and exposes its public interface to the client SCO.

An API Instance is an individual execution context and state of an API Implementation. The API Instance represents the piece of executing software that the SCO interacts with during the SCOs operation.

A key aspect of the API is to provide a communication mechanism that allows the SCO to communicate with the LMS. It is assumed that once the SCO is launched it can then store and retrieve information with an LMS. All communication between the LMS and the SCO is initiated by the SCO. There is currently no supported mechanism for LMSs to initiate calls to functions implemented by a SCO.
Data Model
The purpose of establishing a common data model is to ensure that a defined set of information about SCOs can be tracked by different LMS environments. If, for example, it is determined that tracking a learner’s score is a general requirement, then it is necessary to establish a common way for content to report scores to LMS environments.
If SCOs use a unique scoring representation, LMSs may not know how to receive, store or process the information.

The SCORM Run-Time Environment Data Model is based on the P1484.11.1 Draft Standard for Learning Technology - Data Model for Content Object Communication standard produced by the IEEE LTSC Computer Managed Instruction (CMI).
P1484.11.1 is a standard that defines a set of data model elements that can be used to communicate information from a content object (i.e., SCO in SCORM) to an LMS. This set of data includes, but is not limited to, information about the learner, interactions that the learner had with the SCO, objective information, success status and completion status. This information may be vital for many purposes. This data can be used to track the learner’s progress and status, aid in sequencing decisions and report on the overall learner interaction with the SCO.
Image for 'Data Model'
Using the data model with the API
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
Free to distribute for non-commercial purposes.
Print
General Information
Title: SCORM 2004 4th Edition: RTE Version 1.1
Version: 2004 3rd Edition 1.1
Director: Paul Jesukiewicz
Technical Editor: Angelo Panar
Release Date: 14 August 2009
Status: Final

Electronic Version: Online available (SCORM 2004 4th Ed. Documentation Suite)
Tracking of changes
  • Miscellaneous minor edits and clarifications
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the ADL web site and edited for presentation. Please refer to the ADL web site for additional information on terms of use.
Print
Version 2004 4th Edition 1.0
Title: SCORM 2004 4th Edition: RTE Version 1.0
Version: 2004 3rd Edition 1.0
Editor: Philip Dodds
Release Date: 31 March 2009
Status: Final

Electronic Version: Not online available


Tracking of changes:
  • Miscellaneous minor edits and clarifications.
  • Updated usage of element and application of partial completion tracking.
  • Incorporated ADL Run-Time Data Model extensions for non-objective inter-SCO shared global storage.
Version 2004 3rd Edition
Title: SCORM Run-Time Environment
Version: 2004 3rd Edition
Editor: Philip Dodds
Release Date: 20 October 2006
Status: Final

Tracking of changes:
  • Changes due to standardization/specification efforts, in particular the IMS Content Packaging Specification Version 1.1.4 and IEEE Standard for Learning Technology - Extensible Markup Language (XML) Schema Definition Language Binding for Learning Object Metadata.
  • Clarification of concepts.
  • Clarification of requirements.
  • Best practices from the ADL Community.
  • Enhancements.
  • Bug fixes.
Version 1.3.1
Title: SCORM Run-Time Environment
Version: 1.3.1
Editor: Philip Dodds
Release Date: 22 July 2004
Status: Final

Electronic Version: Not online available


Tracking of changes:
  • Changes due to IEEE P1484.11.1 Draft 1/WD 13 Draft Standard for Learning Technology – Data Model for Content Object Communication.
  • Changes due to IEEE P1484.11.2 Draft 4 Standard forLearning Technology – ECMAScript Application Programming Interface for Content to Runtime Services Communication.
  • Changes reflecting IMS Simple Sequencing Version 1.0
  • Changes reflecting IMS Content Packaging Version 1.1.3
  • Changes due to IEEE P1484.11.1, Draft 3 Draft Standard for Learning Technology – Data Model for Content Object Communication.
  • Changes due to IEEE 1484.11.2 – Standard for Learning Technology – ECMAScript Application Programming Interface for Content to Runtime Services Communication
Version 1.2
Title: The SCORM Run-Time Environment
Version: 1.2
Editor: Philip Dodds
Release Date: 1 October 2001
Status: Final

Electronic Version: Not online available


Tracking of changes:
This version of the SCORM presents the Run-time Environment definition as a separate document.

Changes include:

  • Added more detail in the Launch Section to describe the launching of more than just SCOs.
  • Added SCO To LMS Communications API State transition diagram and explaination.
  • Added more specifics to the API Error code usage table to indicate when certain error codes should be used.
  • Added more clarifcation to the following data model elements: cmi.core.lesson_status, cmi.core.entry, cmi.core.exit, cmi.core.session_time.
  • Added more specific definition to those elements that represent scores (cmi.core.score.raw, cmi.core.score.min, cmi.core.score.max, cmi.objectives.n.score.raw, cmi.objectives.n.score.min, cmi.objectives.n.score.max). Added a statement that says: “must be a normalized value between 0 and 100”.
  • Added section 3.5 Run-Time Environment Behavior section.
  • General grammar clean up.
Version 1.1
Title: Sharable Content Object Reference Model Version 1.1
Version: 1.1
Editor: Philip Dodds
Release Date: 16 January 2001
Status: Final

Electronic Version: Not online available


Tracking of changes:
Added more detail to each sub-section of the Run-Time Environment section (Launch, API and Data Model).
  • Run-Time Environment Launch changes: Added more detail in describing the launching of SCOs.
  • Run-Time Environment API changes: LMSInitialize(“”), LMSFinish(“”) and LMSCommit(“”) now must all take in an empty string as a parameter. LMSInitialize(“”), LMSFinish(“”), LMSCommit(“”) and LMSSetValue() must now all return a string that can be converted to a CMIBoolean (“true” or “false”). More detailed information on the descriptions of each of the API calls. Added API Error Code usage section. Changed findAPI() algorithm to no longer search the sibling frames.
  • Run-Time Environment Data Model changes: Added new table to describe in detail all data model elements.
Version 1.0
Title: Sharable Courseware Object Reference Model (SCORM)
Version: 1.0
Editor: Philip Dodds
Release Date: 31 January 2000
Status: Draft

Electronic Version: Not online available


Tracking of changes:
SCORM Version 1.0 was the inaugural release of specifications and guidelines to meet the US DoD's high level requirements of accessibility, interoperability, durability and reusability of Web-based learning content and systems. This release represented a work in progress. It comprised three major elements:
  • Course Structure Format
  • Run-Time Environment
  • Meta-data
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send