Home > Articles > Software Development & Management > Architecture and Design

Modeling and Analysis with the AADL: The Basics

In this chapter, the authors illustrate the development of basic AADL models and present general guidance on the use of some of the AADL’s core capabilities in order to provide a basic understanding of architectural modeling and analysis and start you on your way in applying the AADL to more complex software-dependent systems.
This chapter is from the book

While reading the first part of this chapter, you may want to use an AADL development tool to create the specifications and conduct the analyses described. OSATE supports all of the modeling and analyses discussed in this chapter.

3.1. Developing a Simple Model

In this section, we present a step-by-step development and analysis of an AADL model. Specifically, we model a control system that provides a single dimension of speed control and demonstrate some of the analyses that can be conducted on this architectural model. The speed control functionality is part of a powerboat autopilot (PBA) system that is detailed in Appendix A. While specialized to a powerboat, this model exemplifies the use of the AADL for similar control applications such as aeronautical, automotive, or land vehicle speed control systems.

The approach we use is introductory, demonstrating the use of some of the core elements and capabilities of the AADL. We do not include many of the broader engineering capabilities of the language. For example, we do not address packages, prototypes, or component extensions in developing this simple model. These are discussed later in this chapter. Instead, we proceed through the generation of a basic declarative model and its instance and show a scheduling analysis of the system instance. During your reading of this section, you may want to reference Part II for details on specific AADL elements or analyses used in the example.

Initially we create a high-level system representation using AADL system, process, and device components. Building on this initial representation, we detail the runtime composition of all of the elements; allocate software to hardware resources; and assign values to properties of elements to a level that is required for analysis and for the creation of an instance of the system. In these steps, we assume that requirements are sufficiently detailed to provide a sound basis for the architectural design decisions and trade-offs illustrated in the example. In addition, while we reference specific architectural development and design approaches that put the various steps into a broader context, we do not advocate one approach over another.

3.1.1. Defining Components for a Model

A first step is to define the components that comprise the system and place their specification in packages. The process of defining and capturing components is similar to identifying objects in an object-oriented methodology. It is important to realize that components may include abstract encapsulations of functionality as well as representations of tangible things in the system and its environment. The definition of components is generally an iterative and incremental process, in that the first set of components may not represent a complete set and some components may need to be modified, decomposed, or merged with others.

First, we review the description of the speed controller for the PBA and define a simplified speed control model. In this model, we include a pilot interface unit for input of relevant PBA information, a speed sensor that sends speed data to the PBA, the PBA controller, and a throttle actuator that responds to PBA commands.

For each of the components identified, we develop type definitions, specifically defining the component’s name, runtime category, and interfaces. Since we are initially developing a high-level (conceptual) model, we limit the component categories to system, process, and device.

The initial set of components is shown in Table 3-1, where both the AADL text and corresponding graphical representations are included. For this example, the textual specifications of all of the components required for the model are contained in a single package and no references to classifiers outside the package are required. Thus, a package name is not needed when referencing classifiers. For the graphical representations, the implementation relationship is shown explicitly. Note that the icon for an implementation has a bold border when compared to the border of its corresponding type icon.

Table 3-1. Component Type and Implementations for the Speed Control Example

The speed sensor, pilot interface, and throttle actuator are modeled as devices and the PBA control functions are represented as a process. We use the devices category for components that are interfaces to the external environment that we do not expect to decompose extensively (e.g., a device can only have a bus as a subcomponent).

Devices in AADL can represent abstractions of complex components that may contain an embedded processor and software. With a device component, you represent only those characteristics necessary for analysis and an unambiguous representation of a component. For example, in modeling a handheld GPS receiver, we may only be interested in the fact that position data is available at a communication port. The fact that the GPS receiver has an embedded processor, memory, touch screen user interface, and associated software is not required for analysis or modeling of the system. Alternatively, a device can represent relatively simple external components, such as a speed sensor, whose only output is a series of pulses whose frequency is proportional to the speed being sensed. If you require a complex interface to the external environment, you can use a system component. In this case, you can detail its composition and as needed include an uncomplicated device subcomponent to represent the interface to the environment.

The use of a process component for the control functions reflects the decision that the core control processing of the PBA is to be implemented in software. The software runtime components will be contained within an implementation of this process type. The implementation declarations in Table 3-1 do not include any details. As the design progresses, we will add to these declarations (i.e., adding subcomponents and properties as appropriate).

The interfaces for the PBA components are port features declared within a component type and are reflected in each implementation of that type. For example, the type sensor outputs a value of the speed via a data port sensor_data. The pilot interface type interface provides a value for the set speed via a data port set_speed and generates a signal to disengage the speed control via an event port disengage.

Notice that we have used explicit as well as abbreviated naming for the ports and other elements of the model (e.g., command_data and cmd for the command data at input and output ports). The specificity of names is up to you, provided they comply with AADL naming constraints for identifiers (e.g., the initial character cannot be a numeral). Note that naming is case insensitive and Control is the same name as control.

In the PBA example, we have chosen to assign specific runtime component categories to each of the components (e.g., the speed sensor is a device). However, in real-world development as a design matures, the definition of these components may change (e.g., a component that computes the PBA speed control laws may initially be represented as a system and later modified to a process or thread). Using the approach we outline here, these changes are done manually within the AADL model (i.e., changing a system declaration to a process category declaration). An alternative approach is to use the generic abstract component category (i.e., not defining a specific runtime essence). Then later in the development, converting this abstract category into a specific runtime category employing the AADL extends capability (e.g., converting an abstract component to a thread). We have chosen to use the former approach to simplify the presentation and focus on decisions and issues related to representations of the system as concrete runtime components. A discussion of the use of the abstract component category is provided in Section 3.5.

For each of the component types we define a single implementation. These declarations are partial, in that we omit substantial details needed for a complete specification of the architecture. For example, we do not define the type of data that is associated with the ports. We will address these omissions as required in later steps. However, we can conduct a number of analyses for our simple example without including many of these details.

3.1.2. Developing a Top-Level Model

In the next step, we integrate the individual component implementations into a system by declaring subcomponents instances and their connections. We do this by defining an enclosing system type and implementation as shown in Listing 3-1, where we define a system type Complete and its implementation Complete.PBA_speed_control. There is nothing special about our choice of naming for this enclosing system. Another naming scheme, such as a type of PBA and an implementation of PBA.speed, would work as well.

Within the implementation, we declare four subcomponents. The three device subcomponents represent the speed sensor, throttle, and the pilot interface unit. The process subcomponent speed_control represents the software that provides the speed control for the PBA. Notice that there are no external interfaces for the system type Complete. All of the interactions among the system’s subcomponents are internal to the implementation Complete.PBA_speed_control, with the devices that comprise the system providing the interfaces to the external environment (e.g., sensors determining speed information from the vehicle).

Within the implementation, we define connections for each of the ports of the subcomponents. For example, connection DC2 is the data connection between the command_data port on the process speed_control and the cmd data port on the device throttle. Each of the connections is labeled in the graphical representation shown in Listing 3-1 by the nature of the connection.1 For example, connection EC4 between the event port disengage on the interface_unit device and the event port disengage on the speed_control process is labeled as <<Event>>. It is our choice to match most of the port names. It is not required that connected ports have the same name. However, they must have matching data classifiers if specified (they are omitted in this initial representation).

Listing 3-1. Subcomponents of the Complete PBA System

system Complete
end Complete;

system implementation Complete.PBA_speed_control
  subcomponents
    speed_sensor: device sensor.speed;
    throttle: device actuator.speed;
    speed_control: process control.speed;
    interface_unit: device interface.pilot;
  connections
    DC1: port speed_sensor.sensor_data ->
         speed_control.sensor_data;
    DC2: port speed_control.command_data -> throttle.cmd;
    DC3: port interface_unit.set_speed ->
         speed_control.set_speed;
    EC4: port interface_unit.disengage ->
         speed_control.disengage;
end Complete.PBA_speed_control;

Depending upon your development environment the graphical portrayals may differ from those shown in Listing 3-1. For example, within OSATE you cannot display the containment explicitly. Rather, the internal structure of an implementation is presented in a separate diagram that can be accessed hierarchically through the graphical icon representing the implementation Complete.PBA_speed_control.

3.1.3. Detailing the Control Software

At this point, we begin to detail the composition of the process speed_control. This involves decisions relating to partitioning the functionality and responsibilities required of the PBA system to provide speed control. Since we have treated the speed control as an autonomous capability, we have implicitly assumed that there are no interactions between the directional or other elements of the PBA and the speed control system. This may not be the case in advanced control systems. In addition, for the purposes of this example, we partition the functions of the speed control process into two subcomponents. The first is a thread that receives input from speed sensor; scales and filters that data; and delivers the processed data to the second thread. The second is a thread that executes the PBA speed control laws and outputs commands to the throttle actuator. Again, this simplification may not be adequate for a realistic speed control system (e.g., the control laws may involve extensive computations that for efficiency must be separated into multiple threads or may involve complex mode switches that are triggered by various speed or directional conditions)2.

Since the interfaces for the two threads are different, we define a type and implementation for each, as shown in Listing 3-2. We have used property associations to assign execution characteristics to the threads. Each is a periodic thread (assigned using the Dispatch Protocol property association) with a period of 50ms (assigned using the Period property association).

The assignment of periodic execution and the values for the period of the threads reflect design decisions. Generally, these are based upon the input of application domain and/or control engineers. The assignments we use here are not necessarily optimal but are chosen to provide specific values to enable analysis of system performance. They do not reflect the values for any specific control system.

Listing 3-2. PBA Control Threads Declarations

thread read_data
  features
    sensor_data: in data port;
    proc_data: out data port;
  properties
    Dispatch_Protocol => Periodic;
    Period => 50 ms;
end read_data;

thread implementation read_data.speed
end read_data.speed;

thread control_laws
  features
    proc_data: in data port;
    cmd: out data port;
    disengage: in event port;
    set_speed: in data port;
  properties
    Dispatch_Protocol => Periodic;
    Period => 50 ms;
end Control_laws;

thread implementation control_laws.speed
end control_laws.speed;

We detail the declaration of the process implementation control.speed that is presented in Table 3-1 to include the two thread subcomponents and their interactions (connections), as shown in Listing 3-3. There are five connections declared. Four of these connect ports on the boundary of the process with ports on the threads (i.e., DC1, DC3, DC4, and EC1). The fifth connects the out data port proc_data on the thread scale_speed_data to the in data port proc_data on the thread speed_control_laws.

Listing 3-3. The Process Implementation control.speed

process implementation control.speed
  subcomponents
    scale_speed_data: thread read_data.speed;
    speed_control_laws: thread control_laws.speed;
  connections
    DC1: port sensor_data -> scale_speed_data.sensor_data;
    DC2: port scale_speed_data.proc_data ->
      speed_control_laws.proc_data;
    DC3: port speed_control_laws.cmd -> command_data;
    EC1: port disengage -> speed_control_laws.disengage;
    DC4: port set_speed -> speed_control_laws.set_speed;
end control.speed;

3.1.4. Adding Hardware Components

At this point, we have defined the software components of the speed control system. We now define the execution hardware required to support the software. In modeling the hardware and binding the control software to that hardware, we can analyze the execution timing and scheduling aspects of the system.

In Listing 3-4, we define a processor, memory, and bus. The processor will execute the PBA control code (threads) and the memory will store the executable code (process) for the system. In addition, we have declared that the processor type Real_Time and the memory type RAM require access to an instance of the bus implementation Marine.Standard. This bus will provide the physical pathway for the system. We will add properties to these declarations later in the modeling process.

Listing 3-4. Execution Platform Declarations

processor Real_Time
  features
    BA1: requires bus access Marine.Standard;
end Real_Time;
processor implementation Real_Time.one_GHz
end Real_Time.one_GHz;

memory RAM
  features
    BA1: requires bus access Marine.Standard;
end RAM;
memory implementation RAM.Standard
end RAM.Standard;

bus Marine
end Marine;

bus implementation Marine.Standard
end Marine.Standard;

3.1.5. Declaring Physical Connections

To continue the integration of the system, we add instances of the required execution platform components into the system implementation Complete.PBA_speed_control by declaring subcomponents for the implementation. In addition, we declare that these components are attached to the bus. This is done by connecting the requires interfaces on the processor and memory components to the bus component.

Since the PBA control software executing on the processor must receive data from the sensors and pilot interface unit as well as send commands to the throttle actuator, we declare that these sensing and actuator devices are connected to the bus as well. To do this, we add requires bus access declarations in the type declarations for these three devices and connect them to the bus. The updated declarations for the three devices are shown in Listing 3-5 and the graphical representation of the system with the declaration of the physical (bus access) connections is shown in Listing 3-6.

Listing 3-5. Updated Device Declarations

device interface
  features
    set_speed: out data port;
    disengage: out event port;
    BA1: requires bus access Marine.Standard;
end interface;

device sensor
  features
    sensor_data: out data port;
    BA1: requires bus access Marine.Standard;
end sensor;

device actuator
  features
    cmd: in data port;
    BA1: requires bus access Marine.Standard;
end actuator;

In Listing 3-6, we have defined a processor RT_1GHz 3, bus Standard_Marine_Bus, and memory Stand_Memory as subcomponents. In addition, we have declared the connections for the bus Standard_Marine_Bus to the requires bus access features of each of the physical components (e.g., from Standard_Marine_Bus to RT_GHz.BA1 and to the requires bus access feature on the processor RT_1GHz.BA1). The requires access features and the bus access connections are shown in the graphical representation in the lower portion of Listing 3-6.

Listing 3-6. Integrated Software and Hardware System

system implementation Complete.PBA_speed_control
  subcomponents
    speed_sensor: device sensor.speed;
    throttle: device actuator.speed;
    speed_control: process control.speed;
    interface_unit: device interface.pilot;
    RT_1GHz: processor Real_Time.one_GHz;
    Standard_Marine_Bus: bus Marine.Standard;
    Stand_Memory: memory RAM.Standard;
  connections
    DC1: port speed_sensor.sensor_data ->
         speed_control.sensor_data;
    DC2: port speed_control.command_data -> throttle.cmd;
    DC3: port interface_unit.set_speed ->
         speed_control.set_speed;
    EC4: port interface_unit.disengage ->
         speed_control.disengage;
    BAC1: bus access Standard_Marine_Bus <-> speed_sensor.BA1;
    BAC2: bus access Standard_Marine_Bus <-> RT_1GHz.BA1;
    BAC3: bus access Standard_Marine_Bus <-> throttle.BA1;
    BAC4: bus access Standard_Marine_Bus <-> interface_unit.BA1;
    BAC5: bus access Standard_Marine_Bus <-> Stand_Memory.BA1;
end Complete.PBA_speed_control;

3.1.6. Binding Software to Hardware

In addition to specifying the physical connections, we bind software components to the appropriate physical hardware using contained property associations, as shown in Listing 3-7. These property associations are added to the system implementation declaration Complete.PBA_speed_control. The first two declarations allow the threads speed_control_laws and scale_speed_data to be bound to the processor rt_mhz500. The reference part of the property association identifies the specific processor instance rt_mhz500 and the applies to identifies the specific thread in the hierarchy (e.g., applies to speed_control.scale_speed_data identifies the thread scale_speed_data that is located in the process speed_control). In this notation, a period separates the elements in the hierarchy.

We could have specified a specific binding using the Actual_Processor_Binding property. However, the Allowed_Processor_Binding property permits scheduling tools to assign the threads to processors. For example, the resourced allocation and scheduling analysis plug-in that is available in the OSATE environment 4 binds threads to processors taking into consideration the threads’ period, deadline, and execution time; processor(s) speed and scheduling policies; and the constraints imposed by the actual and allowed binding properties 5. Specifically, if only allowed processor bindings are defined (i.e., the Allowed_Processor_Binding property), the plug-in schedules the thread onto processors and reports back the actual thread to processor bindings and the resulting processor utilizations. If actual processor bindings are defined (i.e., the Actual_Processor_Binding property) the plug-in reports processor utilization based upon those bindings; allocates threads to processors; and runs a scheduling analysis to determine whether the bindings are acceptable.

The third entry in Listing 3-7, binds the code and data within the process speed_control to the memory component Standard_Memory. We chose to use the actual rather than the allowed memory binding property, since there is only one memory component in the system and, while an additional processor might be added, we do not anticipate additional memory components to be added.

Listing 3-7. Binding Property Associations

properties
  Allowed_Processor_Binding => (reference(RT_1GHz))
    applies to speed_control.speed_control_laws;
  Allowed_Processor_Binding => (reference(RT_1GHz))
    applies to speed_control.scale_speed_data;
  Actual_Memory_Binding => (reference(Stand_Memory))
    applies to speed_control;

3.1.7. Conducting Scheduling Analyses

Having defined the threads and established their allowed bindings to processors, we can begin to assess processor loading and analyze the schedulability of the system.

Before we proceed with a scheduling analysis, we define the requisite execution characteristics for the threads as they relate to the capabilities of the processors to which they may be bound. We specify this information through properties of the threads and processors. In this case, there is only one processor with an execution speed of 1GHz, as shown in Listing 3-8. Both threads are declared as Periodic with a period of 50ms. The default value in the AADL standard for the Deadline is the value of the Period. This value can be overridden by assigning a value to the Deadline using a property association. The execution time of the read_data thread ranges from 1 millisecond (ms) to 2 milliseconds (ms), whereas the control_laws thread’s execution time ranges from 3ms to 5ms (as assigned using the Compute_Execution_Time property associations). These execution times are relative to the processor Real_Time.one_GHz declared in the model 6.

Execution time estimates for the threads can be based upon timing measurements from prototype code or historical data for similar systems (e.g., systems with the same or comparable processors). By conducting the analysis early in the development process, you can get quantitative predictions of a system’s performance. This information can be updated and re-evaluated as the design progresses. These early and continuing predictions can help to avoid last minute problems during code implementation and system integration (e.g., during testing when deadlines are not met because the processor loading exceeds the capability of the processor).

Listing 3-8. Updated Declarations for Analysis

thread read_data
  features
    sensor_data: in data port;
    proc_data: out data port;
  properties
    Dispatch_Protocol => Periodic;
    Compute_Execution_Time => 1 ms .. 2 ms;
    Period => 50 ms;
end read_data;

thread control_laws
  features
    proc_data: in data port;
    cmd: out data port;
    disengage: in event port;
    set_speed: in data port;
  properties
    Dispatch_Protocol => Periodic;
    Compute_Execution_Time => 3 ms .. 5 ms;
    Period => 50 ms;
end Control_laws;

At this point, we have defined a declarative model for a simple speed control system including all of the components, properties, and bindings to describing a deployment configuration. From the top-level system implementation of this declarative model you create a system instance model and analyze it with the OSATE scheduler and scheduling analysis plug-in.

In Figure 3-1, we show the results of that analysis. It shows that the two threads in the system only use 14% of the processor capabilities. The worst case execution time for the two threads is 7ms, which is 14% of their 50 millisecond period.

Figure 3-1

Figure 3-1. Processor Capacities of the Speed Control System Instance

Notice the information provided by the plug-in, including the actual binding for the threads determined by the plug-in (as shown in the cropped output of Figure 3-2).

Figure 3-2

Figure 3-2. Bindings from the OSATE Scheduler and Scheduling Analysis Plug-in

3.1.8. Summary

At this point, we have developed a basic architectural model of the PBA speed control system. In so doing, we have demonstrated some of the core capabilities of the AADL. For this relatively simple model, we analyzed the execution environment and made predictions of schedulability of the system. In subsequent sections, we describe additional capabilities of the AADL and discuss alternative modeling approaches that can be applied in this simple example.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020