Search

While many secondary schools offer courses or extracurricular activities that focus on satellite engineering, e.g. CanSats or the assembly of ground stations, these projects usually stay close to ground. With SpaceTeamSat1, the TU Wien Space Team wants to enhance this approach and tackle the challenge to perform various experiments in space, enabling students to participate in a space mission that actually orbits our planet. Therefore, our goal is to develop a 1U CubeSat platform, which allows students at secondary schools to access a set of different sensors connected to a Raspberry Pi. Consequently, students can write their own software experiments in Python and exploit the possibilities of sensors in space. In this context, participation happens at different stages: For one, students are getting in contact with Python, which also allows an easy step into software engineering paradigms. Moreover, our team will pose some challenges, such as re-doing an earlier satellite mission and giving impressions about how CubeSats can be used, e.g. to combat climate change. To complete these challenges, the CubeSat is equipped with various sensors such as temperature sensors, gyrometers, magnetometers, as well as two cameras. Moreover, the participating students also have the possibility to design their own experiments independently to leave room for creativity. Further enhancing this educational mission, participating students are also invited to work on hardware topics. This is mainly aimed at engineering schools, which are encouraged to assemble Raspberry Pi HATs which contain the actual mission sensors, as well as a SatNOGS ground station, which also enables students to get an insight on satellite communication. It needs to be considered that the educational mission follows a modular setup since the combination of all individual tasks is not realizable within a single school year. Thus, schools are also able to individually select appropriate tasks. In the past we were already collaborating with the European Space Education Resource Office as we are acting as launch provider of CanSats for ESERO’s Austrian CanSat competition. In this sense, STS1 shall be an extension to the space educational program in Austria. Based on that, we believe that the STS1 mission has a high potential to bring something that is currently out of reach for most people, outer space, closer to a demographic with a lot of talent and enthusiasm for engineering and potential future engineers

Concurrent engineering is an approach to the development of complex systems that is char- acterised by direct communication between the disciplines involved. Instead of processing the individual disciplines one after the other, as in sequential design, or processing via a single contact person, as in centralised design, all systems work simultaneously. Learning this inter- action and understanding what information needs to be communicated between disciplines are among the central learning objectives of the course "Spacecraft Design" at Technische Uni- versität Dresden, Institute of Aerospace Engineering. In this course, the students represent different disciplines and work out a mission study that is commissioned by the lecturers. The lecturers thus participate in the development process in the role of customers. Key to the concurrent engineering approach is that each discipline has access to the most current design data at all times. This can be done via a dedicated software solution. Both commercial and open source software tools are available. Within the frame of the above-men- tioned course, several tools have been tested. The covered software solutions comprise ESA Open Concurrent Design Tool (OCDT), RHEA Concurrent Design Platform (CDP), Valispace and IBM Rhapsody. This contribution presents the experience that we gathered with these concurrent engineering software tools. First, the tools are described and their commonalities and distinctions are high- lighted. Subsequently, a detailed trade-off between the tools is being presented. This trade-off will particularly focus on the utilisation of these tools within the scope of course work at univer- sities, as this entails special requirements and boundary conditions, such as very limited time for introducing the software, highly heterogeneous user group, limited utilisation of the software in terms of depth and functionality, to only name a few. Within this contribution, we will also explore alternative approaches, such as using no software at all. The aim of this contribution is to offer other teachers and students some guideline for selecting a concurrent engineering software solution and implementing it in course work, in a way that using the tool itself does not become the central learning challenge of the course. The results might be of interest beyond university courses, as some requirements, like short times to get familiar with the software or certain interface requirements, also apply to other environments in research and development.