A Lightweight Multilevel Markup Language for Connecting Software Requirements and Simulations

[Context] Simulation is a powerful tool to validate specified requirements especially for complex systems that constantly monitor and react to characteristics of their environment. The simulators for such systems are complex themselves as they simulate multiple actors with multiple interacting functions in a number of different scenarios. To validate requirements in such simulations, the requirements must be related to the simulation runs. [Problem] In practice, engineers are reluctant to state their requirements in terms of structured languages or models that would allow for a straightforward relation of requirements to simulation runs. Instead, the requirements are expressed as unstructured natural language text that is hard to assess in a set of complex simulation runs. Therefore, the feedback loop between requirements and simulation is very long or non-existent at all. [Principal idea] We aim to close the gap between requirements specifications and simulation by proposing a lightweight markup language for requirements. Our markup language provides a set of annotations on different levels that can be applied to natural language requirements. The annotations are mapped to simulation events. As a result, meaningful information from a set of simulation runs is shown directly in the requirements specification. [Contribution] Instead of forcing the engineer to write requirements in a specific way just for the purpose of relating them to a simulator, the markup language allows annotating the already specified requirements up to a level that is interesting for the engineer. We evaluate our approach by analyzing 8 original requirements of an automotive system in a set of 100 simulation runs

SEIS: Insight's Seismic Experiment for Internal Structure of Mars.

By the end of 2018, 42 years after the landing of the two Viking seismometers on Mars, InSight will deploy onto Mars' surface the SEIS (Seismic Experiment for Internal Structure) instrument; a six-axes seismometer equipped with both a long-period three-axes Very Broad Band (VBB) instrument and a three-axes short-period (SP) instrument. These six sensors will cover a broad range of the seismic bandwidth, from 0.01 Hz to 50 Hz, with possible extension to longer periods. Data will be transmitted in the form of three continuous VBB components at 2 sample per second (sps), an estimation of the short period energy content from the SP at 1 sps and a continuous compound VBB/SP vertical axis at 10 sps. The continuous streams will be augmented by requested event data with sample rates from 20 to 100 sps. SEIS will improve upon the existing resolution of Viking's Mars seismic monitoring by a factor of ∼ 2500 at 1 Hz and ∼ 200 000 at 0.1 Hz. An additional major improvement is that, contrary to Viking, the seismometers will be deployed via a robotic arm directly onto Mars' surface and will be protected against temperature and wind by highly efficient thermal and wind shielding. Based on existing knowledge of Mars, it is reasonable to infer a moment magnitude detection threshold of M w ∼ 3 at 40 ∘ epicentral distance and a potential to detect several tens of quakes and about five impacts per year. In this paper, we first describe the science goals of the experiment and the rationale used to define its requirements. We then provide a detailed description of the hardware, from the sensors to the deployment system and associated performance, including transfer functions of the seismic sensors and temperature sensors. We conclude by describing the experiment ground segment, including data processing services, outreach and education networks and provide a description of the format to be used for future data distribution.Electronic supplementary materialThe online version of this article (10.1007/s11214-018-0574-6) contains supplementary material, which is available to authorized users

Incremental Reconfiguration of Product Specific Use Case Models for Evolving Configuration Decisions

[Context and motivation] Product Line Engineering (PLE) is increasingly common practice in industry to develop complex systems for multiple customers with varying needs. In many business contexts, use cases are central development artifacts for requirements engineering and system testing. In such contexts, use case configurators can play a significant role to capture variable and common requirements in Product Line (PL) use case models and to generate Product Specific (PS) use case models for each new customer in a product family. [Question/Problem] Although considerable research has been devoted to use case configurators, little attention has been paid to supporting the incremental reconfiguration of use case models with evolving configuration decisions. [Principal ideas/results] We propose, apply, and assess an incremental reconfiguration approach to support evolving configuration decisions in PL use case models. PS use case models are incrementally reconfigured by focusing only on the changed decisions and their side effects. In our prior work, we proposed and applied Product line Use case modeling Method (PUM) to support variability modeling in PL use case diagrams and specifications. We also developed a use case configurator, PUMConf, which interactively collects configuration decisions from analysts to generate PS use case models from PL models. Our approach is built on top of PUM and PUMConf. [Contributions] We provide fully automated tool support for incremental configuration as an extension of PUMConf. Our approach has been evaluated in an industrial case study in the automotive domain, which provided evidence it is practical and beneficial

Constraints on the shallow elastic and anelastic structure of Mars from InSight seismic data

Mars’s seismic activity and noise have been monitored since January 2019 by the seismometer of the InSight (Interior Exploration using Seismic Investigations, Geodesy and Heat Transport) lander. At night, Mars is extremely quiet; seismic noise is about 500 times lower than Earth’s microseismic noise at periods between 4 s and 30 s. The recorded seismic noise increases during the day due to ground deformations induced by convective atmospheric vortices and ground-transferred wind-generated lander noise. Here we constrain properties of the crust beneath InSight, using signals from atmospheric vortices and from the hammering of InSight’s Heat Flow and Physical Properties (HP3) instrument, as well as the three largest Marsquakes detected as of September 2019. From receiver function analysis, we infer that the uppermost 8–11 km of the crust is highly altered and/ or fractured. We measure the crustal diffusivity and intrinsic attenuation using multiscattering analysis and find that seismic attenuation is about three times larger than on the Moon, which suggests that the crust contains small amounts of volatiles

SEIS: Insight’s Seismic Experiment for Internal Structure of Mars

By the end of 2018, 42 years after the landing of the two Viking seismometers on Mars, InSight will deploy onto Mars’ surface the SEIS (Seismic Experiment for Internal Structure) instrument; a six-axes seismometer equipped with both a long-period three-axes Very Broad Band (VBB) instrument and a three-axes short-period (SP) instrument. These six sensors will cover a broad range of the seismic bandwidth, from 0.01 Hz to 50 Hz, with possible extension to longer periods. Data will be transmitted in the form of three continuous VBB components at 2 sample per second (sps), an estimation of the short period energy content from the SP at 1 sps and a continuous compound VBB/SP vertical axis at 10 sps. The continuous streams will be augmented by requested event data with sample rates from 20 to 100 sps. SEIS will improve upon the existing resolution of Viking’s Mars seismic monitoring by a factor of ∼ 2500 at 1 Hz and ∼ 200 000 at 0.1 Hz. An additional major improvement is that, contrary to Viking, the seismometers will be deployed via a robotic arm directly onto Mars’ surface and will be protected against temperature and wind by highly efficient thermal and wind shielding. Based on existing knowledge of Mars, it is reasonable to infer a moment magnitude detection threshold of Mw ∼ 3 at 40◦ epicentral distance and a potential to detect several tens of quakes and about five impacts per year. In this paper, we first describe the science goals of the experiment and the rationale used to define its requirements. We then provide a detailed description of the hardware, from the sensors to the deployment system and associated performance, including transfer functions of the seismic sensors and temperature sensors. We conclude by describing the experiment ground segment, including data processing services, outreach and education networks and provide a description of the format to be used for future data distribution

System Testing of Product Lines: From Requirements to Test Cases

Product line processes still lack support for testing end-product functions by taking advantage of the specific features of a product line (commonality and variabilities). Indeed, classical testing approaches cannot be directly applied on each product since, due to the potentially huge number of products, the testing task would be far too long and expensive. There is thus a need for testing methods, adapted to the product line context, that allow reducing the testing cost. The approach we present is based on the automation of the generation of application system tests, for any chosen product, from the system requirements of a product line. These PL requirements are modeled using enhanced UML use cases which are the basis for the test generation. Product-specific test objectives, test scenarios, and test cases are successively generated through an automated process. The key idea of the approach is to describe func-tional variation points at requirement level to automatically generate the behaviors specific to any chosen product. With such a strategy, the designer may apply any method to produce the domain models of the product line and then instantiate a given product: the test cases derived from product-specific behaviors are executed against the chosen end product t