Article

The SAO-IIS Communication Package

Authors:
To read the full-text of this research, you can request a copy directly from the authors.

Abstract

Cooperating processes send image data to saoimage (or imtool ) via the IIS transimission protocol. Due to the lack of an easy-to-use subroutine library, relatively few applications have, to date, made use of this feature. With sao-iis , we provide a package that programmers can use to send image data to saoimage (or imtool ) via the IIS protocol. We describe three applications of sao-iis : two data taking systems and an image analysis tool for segment stacking. We discuss options for coordinating multiple clients of saoimage (or imtool ). Finally, we discuss the future of display server communications.

No full-text available

Request Full-text Paper PDF

To read the full-text of this research,
you can request a copy directly from the authors.

... EMT Homepage. Source(BEGEY, 2015) ...
Thesis
Full-text available
In a global economy, the conquest of exploring and acquiring new markets has led many companies to expand their business around the globe. Many companies adopted a strategy of shifting from a centralized company where products were designed and manufactured in one region to a decentralized company, and then to a distributed organization over the regions. Our thesis context is GE Renewable Energy – Hydro solutions that designs and manufactures hydraulic power plants. GE hydro organization is scattered over 5 regions (North America, Latin America, Europe, China and India). Each region became part of this distributed organization where they participated in the designing and the manufacturing of the hydraulic turbines/ generators. However, new challenges arose in this distributed product development process: specific market needs, different working practices, various design methods, multitude of design tools in addition to the cultural differences among the regions.In order to rationalize the regional differences, the distributed development of hydraulic turbines and generators entailed several objectives. For example, standardization of engineering processes, development of common design guides for engineering tools, harmonization of quality sheets and troubleshooting procedures. Hydro organization has entrusted these objectives to the virtual engineering collectives who are dispersed in all the regions.Our research aimed at studying and supporting the virtual engineering collectives in the co-creation of corporate engineering standards and guidelines. The virtual engineering collectives involved the designers, industrial engineers, technicians as well as the end-users. They had to remotely collaborate in order to co-develop the engineering standards and later on to adopt them in customer projects.Since the virtual engineering collectives were at the core of our standardization approach, the thesis addressed the following research questions:1-“which collaborative standardization process and platform could enable the engineering collectives to co-develop their standards at distance?”2-“what are the characteristics of the different virtual collectives’ types which suit respectively the collaborative standardization process?”3-“which operational process has to be defined to ease the work of the virtual engineering collectives within a project based management style?”From the literature, we defined and differentiated the virtual engineering collectives’ types as virtual communities of practice and/or interest, virtual teams and networks of learning. Through observations and reflections from the practice, we have developed and tested our propositions. The main thesis’ contributions are summarized as follows:1-The collaborative standardization process to co-develop the engineering standards at distance.2-HySPeC templates – the collaborative standardization platform - to respond to the different requirements of the collaborative standardization process.3-The virtual collectives’ dynamics (VCD) model to characterize the virtual collectives in function of their development phases.4-The virtual collectives’ framework (VCF) to select, differentiate and fit the virtual collectives in function of the project’s objectives.5-The virtual collectives’ operational process to facilitate the adoption and the implementation of the engineering standards in the customers’ projects.The top management at GE Hydro found the proposed collaborative standardization approach able to co-develop the engineering standards at distance. The different virtual collectives’ types can fit and adapt to the collaborative standardization process and intuitively use the collaborative platform’ functionalities. The approach also provided an operational process to facilitate the integration and the work of the virtual engineering collectives within the distributed hydro organization.
Article
On the Keck telescope, autoguiders are not tightly integrated into the telescope control system; an autoguider is just an instrument which happens to have been asked to send guide star positions to the telescope. A standard message interface has been defined, and any source of guide star positions which adheres to this interface can play the role of the autoguider. This means that it would be easy for science instruments with fast readout rates (this of course includes all thermal infra-red instruments) to provide guide star positions. Much of an autoguider's user interface and control logic is independent of the actual source of the guide star positions. Accordingly the Keck telescope has defined an internal ``camera server'' protocol which is used by camera-independent high-level autoguider software to control physical cameras. As yet this protocol is only supported by one type of camera (the Photometrics camera which is used for all Keck autoguiders). Support for other types of camera, for example an infra-red camera, is planned. The poster display will illustrate the Keck approach to autoguiding, will show some of the advantages and disadvantages of the Keck approach, and will discuss future plans.
Article
On the Keck telescope, autoguiders are not tightly integrated into the telescope control system; an autoguider is just an instrument which happens to have been asked to send guide star positions to the telescope. A standard message interface has been defined, and any source of guide star positions which adheres to this interface can play the role of the autoguider. This means that it would be easy for science instruments with fast readout rates (this of course includes all thermal infra-red instruments) to provide guide star positions. Much of an autoguider's user interface and control logic is independent of the actual source of the guide star positions. Accordingly the Keck telescope has defined an internal ``camera server'' protocol which is used by camera-independent high-level autoguider software to control physical cameras. As yet this protocol is only supported by one type of camera (the Photometrics camera which is used for all Keck autoguiders). Support for other types of camera, for example an infra-red camera, is planned. The poster display will illustrate the Keck approach to autoguiding, will show some of the advantages and disadvantages of the Keck approach, and will discuss future plans.