Science Studio is an open source development framework for remote control of scientific apparatus that also provides many other useful services for managing the life cycle of executing experiments, creating proposals for usage of these devices, scheduling resources, and providing a shared collaborative environment where users can share tasks, files, data, and online experiments. It also provides the service oriented infrastructure for integrating with existing systems.

Science Studio is a distributed system that provides the end user with a common interface to the devices and analysis programs they need to run scientific experiments. Science Studio can be set up as a stand alone node or can set up as a satellite nude to a central hub or some combination of the two.

Science Studio serves three main purposes:

  • Management of all aspects of a scientific experiment, including
    • Data storage
    • Collaboration
    • Data processing
  • Control of, or interaction with, remote facilities and devices
  • User Services (sample management, scheduling, online training).

Under REMO, services will be made more generic and services will be added to make it easier to set up Science Studio nodes that can stand alone or access centralized REMO hubs. REMO will provide:

  • Ability to control a more diverse set of devices
  • Additional site specific customizations including look and feel configurations
  • Utilities to make it easier to integrate into existing infrastructure, such as:
    • Enhanced Integration services such as generic parser
    • Message brokering
    • Integrated security services
  • Enhanced and simplified data management
    • Streamed persistence of large data sets
    • Enhanced search
    • Single or batch updates
    • Synchronization of data, locking strategy
  • Enhanced information model
  • Enhanced information processing

Science Studio is built on a Service-Oriented Architecture (SOA) framework where business functions are treated as services. The following diagram (Figure 1) provides a high level overview of how the main services have been organized, and how Science Studio and the Complex Devices interact with the data processing elements that are being developed as a part of the Science Studio project.

Figure 1
Figure 1: High Level Conceptual Architecture

From Figure 1, access to Science Studio by users is through a browser to a common portal at UWO. This portal handles the handles the presentation services (Client Services) for all services regardless of where they are located. The services can reside on application servers on multiple nodes. The portal is crucial, since it enables researchers from any location to access Science Studio facilities via the Internet.

The Client Services Layer provides the server component presentation layer, the services managing the user’s interaction with the system. Unlike traditional web applications, the interface is event-driven, i.e. once the browser interface is initialized, it receives periodic messages from the UI services component indicating which sections of the interface are to be updated. An event-driven architecture is required due to the timeliness (“near real-time”) requirements of Science Studio.

The Business Object Layer provides the business logic between the User Interface and the provided Services. It is made up of three main areas: the User Office, Lab or Experiment Management and Device Management. The User Office is an abstraction business layer for all of the user services. User Services provides the mechanism to create, retrieve, and modify metadata relating to experiments such as projects, sessions, samples, etc. The metadata assists in organizing, automating, and improving the experiment process and data. The Lab or Experiment Management services primary functions are to provide services for setting up experiments, configuring experiments and reviewing the results of experiment. The Device Management service provide access for running experiments and collecting and recording data. The service contains device specific business logic and provides an abstraction for the user from the actual complexity of the scientific devices. It is a layer on top of, not a duplication of, the control systems provided by Device Control Module and device specific control software frameworks like Epics IOCs. There is one device manager service deployed per higher level abstract device, for example: a beamline, an electron microscope, or a camera. Each scientific device will have its own configuration and can be accessed by specific UI services tailored for that device.

The Device Control Modules is a framework provided to make it easier to connect to devices or to the control software that controls the devices. This Device Control Framework provides a standard interface for Science Studio to access control software. This interface can remain make static even when there are changes made to Science Studio or to control software. Currently there is an interface implemented to integrate with Input Output Controllers for EPICS, a common device control framework. The Device Control Modules interface leverages message queue infrastructure.

Service Proxies provide a common access to many services. It is the service proxies that provide access to remote or external data services and to processing services. It is these services that provide the integration glue for connecting Science Studio “nodes” and for connecting to other applications.

The Persistence Layer provides access to Science Studio’s internal database. It provides access to the metadata that is used for coordinating the collaboration of tasks, projects, data, device parameters, and system configuration and settings. It can provide the security controls if the Science Studio node is not accessing a shared security service.

As illustrated in Figure 2 below, access to users is normally through a common portal at UWO. This portal handles the presentation services for all services regardless of where they are located. The services will reside on application servers on multiple nodes. The portal is crucial, since it enables researchers from any location to access Science Studio facilities via the Internet.

Experiment Management Services that are specific to a facility/device can reside at that other facility or they can be located at the same facility. All communication that is within the facilities’ Intranet is accomplished using the Java Messaging Service (JMS). Browser access is by REST or SOAP over HTTP. Communication between servers that go over the Internet will use SOAP over HTTP, both of which are web-services standards. This enables the core infrastructure of Science Studio to be easily extended to accommodate additional devices, databases or analysis software

Figure 2
Figure 2: High Level Component Model

One of the key benefits that Science Studio provides is a common Information Model that can be used across Scientific (multiple disciplines) and Institution (multiple facilities) domains. This common Information Model is used for abstracting scientific devices, for representation experiments, for doing data analysis and for many common user services such as proposal management, sample management, project and task management, user feedback, file transfers, collaboration, security and data management. Figure 3 provides an example of this Information Model.

Figure 3
Figure 3: Experiment Management Information Model