Query: GSoC

title: GSOC 2009: Comparative table between MediaWiki and TikiWiki syntax
abstract: MediaWiki and TikiWiki syntax This page list all the MediaWiki syntax described at http:/www.mediawiki.org/wiki/Markup_spec and the correspondent TikiWiki syntax (if any) In the column "Suported by the importer" possible values are: yes (already working) partially supported (supported with some limitations that are explained in the comments) tricky (not implemented yet but the goal is to support before the end of the project) not supported (there are no plans to support this syntax during this project)

title: Integrating the Cubesat Space Protocol into GSOC's Multi Mission Environment

title: Virtuell aber real Flexible Nutzung von Kontrollraumen am Deutschen Raumflugkontrollzentrum (GSOC)
abstract: Der Betrieb einer Raumfahrtmission erfordert je nach Missionsphase sehr unterschiedliche Ressourcen. Nach einer sehr intensiven Betreuung durch grose Teams wahrend Start, Positionierung und Inbetriebnahme folgt eine meist ruhigere Routinephase, bevor die Pflege eines gealterten Raumfahrzeuges gegen Ende der Mission wieder intensiviert werden muss. Mit dem variierenden Personalaufwand skaliert auch die benotigte Anzahl der Positionen im Kontrollraum. Um unter diesen Voraussetzungen die vorhandenen Kontrollraume effizient nutzen zu konnen, hat das GSOC in den vergangenen Jahren die komplette IT Infrastruktur der Kontrollraume virtualisiert und so einen agilen Multimissionsbetrieb etabliert. Im nachsten Schritt sollen nun auch die modular strukturierten einzelnen Services flexibel nutzbar gemacht werden, um verteilte Betriebsszenarien unter Einbeziehung von Infrastruktur auserhalb der Kontrollraume oder des GSOC zu ermoglichen.

title: GSoC 2017 _ Additions
abstract: Now if we have to calculate expected hitting time the process will take to hit state d if we start from a, we apply the ExpectedT ime function. ExpectedT ime function takes four inputs namely a ctmc class object, initial state i, the final state j that we have to calculate expected hitting time and a logical parameter whether to use RCpp implementation. By default, the function uses RCpp as it is faster and takes lesser time.

title: ATHMoS: Automated Telemetry Health Monitoring System at GSOC using Outlier Detection and Supervised Machine Learning
abstract: Knowing which telemetry parameters are behaving accordingly and those which are behaving out of the ordinary is vital information for continued mission success. For a large amount of different parameters, it is not possible to monitor all of them manually. One of the simplest methods of monitoring the behavior of telemetry is the Out Of Limit (OOL) check, which monitors whether a value exceeds its upper or lower limit. A fundamental problem occurs when a telemetry parameter is showing signs of abnormal behavior; yet, the values are not extreme enough for the OOL check to detect the problem. By the time the OOL threshold is reached, it could be too late for the operators to react. To solve this problem, the Automated Telemetry Health Monitoring System (ATHMoS) is in development at the German Space Operation Center (GSOC) At the heart of the framework is a novel algorithm for statistical outlier detection which makes use of the so called Intrinsic Dimensionality (ID) of a data set. Using an ID measure as the core data mining technique allows us to not only run ATHMoS on a parameter by parameter basis, but also monitor and flag anomalies for multi parameter interactions. By aggregating past telemetry data and employing these techniques, ATHMoS employs a supervised machine learning approach to construct three databases: Historic Nominal data, Recent Nominal data and past Anomaly data. Once new telemetry is received, the algorithm makes a distinction between nominal behaviour and new potentially dangerous behaviour; the latter of which is then flagged to mission engineers. ATHMoS continually learns to distinguish between new nominal behavior and true anomaly events throughout the mission lifetime. To this end, we present an overview of the algorithms ATHMoS uses as well an example where we successfully detected both previously unknown, and known anomalies for an ongoing mission at GSOC.

title: GSoC 2015 student contributions to GenApp and Airavata
abstract: GenApp generates applications on an extensible set of target languages for scientific modules. GenApp utilizes JavaScript object notation (JSON) format for all definition files. To create an application, definition files are created for global directives, menu, and modules. Target languages have definition files detailing the steps mapping code fragments to output. Modules must be wrapped to accept and produce JSON as defined in the module's definition file. Execution models are not defined by GenApp; they are included in target language code fragments. Previously, GenApp included target languages of HTML5/PHP, Qt3/C+ and Qt4/C+ with execution models of direct local execution, a web server, or a web server accessible resource. A Google Summer of Code (GSoC) 2014 student demonstrated Airavata managed execution in GenApp's current target languages. Subsequently, Airavata's API and GenApp have evolved. Two GSoC 2015 students updated the previous Airavata integration to support the current API and extend target languages to include Qt5/C+ Qt5/Android, and Java. GenApp was initially developed to wrap modules utilized in the small angles scattering field but is not restricted to this discipline. The GenApp philosophy is to minimize effort of the researcher to deploy modules and insure preservation in an evolving software landscape. Generated applications are in production and used by small angle scattering researchers.

title: GSOC SoE Editor 2.0 A Generic Sequence of Events Tool
abstract: At the German Space Operations Center (GSOC) two applications had been developed for scheduling operations of Launch and Early Orbit Phases (LEOP) Commissioning Phases or special operations campaigns (e.g. software upload, special orbit maneuvers, etc. one for low earth orbit (LEO) and one for medium (MEO) and geostationary earth orbit (GEO) The experiences of these tools were now merged with the scheduling capabilities of GSOC's generic mission planning application Pinta (Program for interactive timeline analysis) its scheduling library Plato (Planning tool) and the GSOC web based timeline display TimOnWeb.

title: Identity and Access Management with GART (GSOC Access Request Tool)
abstract: Performing Identity and Access Management (IAM) for space mission ground systems is essential to ensure operational security. Establishing an IAM Tool (IAMT) in addition to a manual process is a powerful countermeasure to address cyber security threats. Informing the mission managers at a glance which users currently have access to mission (IT) resources improves transparency and diminishes the risk for identity theft. For instance, transparency leads to a more prompt and strict deletion of users, who no longer need access to resources, thereby eliminating their login data as an attack surface. Access Management is demanded by information security regulations, e.g. ISO27001. Space operations companies need to show compliance with regulations, which require controls to enforce the need to know principle. At the same time, organizations want to help users to gain quick and secure access to the (IT) resources they need. The observation of the defined process can be established much more efficiently by a tool than via a manual and error prone organizational process. This paper describes the approach taken at GSOC to enforce the access management process for all ground systems by implementing an IAMT. A role based workflow, governing (IT) resources, provides accountability and traceability in addition to transparency. The first implementation covers the physical door entry system and the OpenLDAP systems. Other directory services may be added in a modular fashion, e.g. DLR's Active Directory. Identity Management introduces transparency across a user's different access data, such as login names and passwords, in different directories within the organization. The more directories and heterogeneous types of resources exist in an organization, the more important it is to provide an overview of a user's accounts, passwords, and responsibilities, such as changing the password at regular intervals and choosing safe passwords according to different rule sets. Challenges for the approach were the multi mission character of GSOC, since several missions share personnel and resources, and the integration of several directory services into one system, among them two separate OpenLDAP trees with overlapping user entries, and a physically separated database with door access information. Thanks to the established IAMT, access changes are recorded and traceable, both during the review process and afterwards. A future step is to use the IAMT to detect unauthorized changes in directories by regularly polling and comparing the data over time. The IAMT will generate a warning if changes are found without a corresponding approved request, for better control and monitoring of privileged users.

title: Implementation of the True Multi Mission Control Room at GSOC
abstract: Starting in early 2014, one of the large LEOP control rooms at GSOC has been arranged according to the concept of control room virtualization already presented at SpaceOPS 2012. The idea behind this concept is that the needs of future satellite missions could be better satisfied by using modern virtualization techniques instead of the traditional control room setup. The control room can be used in a much more flexible way when it is equipped with standard thin clients without project specific software from which connections to the desktops of different satellite projects running as virtual machines in the server rooms can be established. With this setup, a control room is available for trainings, simulations and operational tasks of several missions without large reconfiguration efforts. The entire system has a redundant design, so that there is no operational impact if one of the components fails. Planning and implementation of all required steps were perfomed by the GSOC network infrastructure group in close cooperation with the system engineers of the PAZ, EDRS A und HAG 1 satellite projects over a period of several months. The system has been continuously improved since then by making adjustments based on feedback given by the users of the control room. Until now, numerous test, training and simulation sessions have been completed successfully, not only with GSOC personnel but also together with international partner organizations. The experience gained up to now has shown that the virtualized control room is a highly reliable system users have been able to work with effectively after only a short introduction. In the near future, the described setup will be used for the LEOP operations of the next satellite mission for which GSOC is responsible. Additionally it is planned that further control rooms will be integrated into the mentioned virtualization solution.

title: Enhancement of DLR/GSOC FDS for Low Thrust Orbit Transfer and Control
abstract: On behalf of possible future missions with electric Propulsion (EP) controlled by DLRs German Space Operations Center (DLR/GSOC) the present operational multi mission Flight Dynamics System (FDS) is enhanced to support the preparation and operations of such types of project. For designing an easily extendable framework, various low thrust Scenarios were considered. Each low thrust phase is modelled by a thrust profile comprising non equidistant thrust vector and constant thrust level. Based on this design several multimission FD software modules are enhanced, e.g. Orbit Determination (OD) and generation of Orbit Related Information (ORI) The low thrust transfer trajectories are optimized by means of the software package ASTOS/GESOP  Demonstrating the extended FDS capabilities by means of a GEostationary Orbit (GEO) positioning reference mission shows an excellent consistency between resulting ephemerides by the optimizer in comparison to the FDS, validating the correct processing of thrust profiles within the implemented system.