Comparison of Tests of Purlins with and Without Cleats

The paper describes a series of tests on Z-section purlins lapped over three spans and subject to wind uplift loading. The purlins were not attached to the rafters by cleats. Sheeting was screw-fastened to the purlins and a range of bridging (bracing) members was used to prevent lateral deflection and twisting. The results of the tests are compared with earlier tests with the same configurations but including cleats at the supports

Compression Tests on Cold-formed Angles Loaded Parallel with a Leg

This paper describes a series of compression tests on cold-formed equal angles with slender cross-section. The angles were tested between pinned ends and loaded axially with eccentric load which caused bending parallel with a leg. The test data are compared with the design rules of the Australian and American specifications for cold-formed and hot-rolled steel structures, as well as the ASCE Standard for the Design of Latticed Steel Transmission Structures. The rules of the specifications for cold-formed steel structures (AS/NZS4600 and AlSI) are shown to be very conservative. The cause of the conservatism is explained and improved design rules are proposed

iPRP: Parallel Redundancy Protocol for IP Networks

Reliable packet delivery within stringent time limits is a key requirement of smart-grid and other industrial communication networks. The Parallel Redundancy Protocol (PRP), used in this context, duplicates packets at the MAC layer over parallel networks and is thus claimed to repair packet loss in 0 ms. However, PRP has several drawbacks: it works only for bridged networks; it requires special hardware; as a layer 2 protocol, it does not have diagnostic tools; it imposes the same MAC addresses to different interfaces, which exacerbates the management difficulty; multicast packet delivery is not natively supported. To address these problems we propose the IP Parallel Redundancy Protocol (IPRP). Unlike PRP, IPRP works in routed networks. It supports UDP applications, unicast or multicast. It is transparent to applications and requires no changes in application software. It is also transparent to the network as IPRP-related packets are regular IP packets; it requires no specific hardware. Operation at the IP layer, possibly with more than two networks makes the design of IPRP very different from PRP. We implemented IPRP in Linux 3.6.11-rt29 using iptables and deployed it on a campus smart grid. We describe our implementation and some performance results

iPRP - the Parallel Redundancy Protocol for IP Networks: Protocol Design and Operation

Reliable packet delivery within stringent delay-constraints is of paramount importance to mission-critical computer applications with hard real-time constraints. Because retransmission and coding techniques counteract the delay requirements, reliability may be achieved through replication over multiple fail-independent paths. Existing solutions, such as the parallel redundancy protocol (PRP), replicate all packets at the MAC layer over parallel paths. PRP works best in local area networks. However, it is not viable for IP networks that are a key element of emerging mission-critical systems. This limitation, coupled with diagnostic inability and lack of security, renders PRP unsuitable for reliable data-delivery in these IP networks. To address this issue, we present a transport-layer solution: the IP parallel redundancy protocol (iPRP). Designing iPRP poses non-trivial challenges in the form of selective packet replication, soft-state and multicast support. iPRP replicates only time-critical unicast or multicast UDP traffic. iPRP requires no modifications to the existing monitoring application, end-device operating system or to the intermediate network devices. It only requires a simple software installation on the end-devices. iPRP has a set of diagnostic tools for network debugging. With our implementation of iPRP in Linux, we show that iPRP supports multiple flows with minimal processing-and-delay overhead. It is being installed in our campus smart-grid network and is publicly available

LEO Download Capacity Analysis for a Network of Adaptive Array Ground Stations

To lower costs and reduce latency, a network of adaptive array ground stations, distributed across the United States, is considered for the downlink of a polar-orbiting low earth orbiting (LEO) satellite. Assuming the X-band 105 Mbps transmitter of NASA s Earth Observing 1 (EO-1) satellite with a simple line-of-sight propagation model, the average daily download capacity in bits for a network of adaptive array ground stations is compared to that of a single 11 m dish in Poker Flats, Alaska. Each adaptive array ground station is assumed to have multiple steerable antennas, either mechanically steered dishes or phased arrays that are mechanically steered in azimuth and electronically steered in elevation. Phased array technologies that are being developed for this application are the space-fed lens (SFL) and the reflectarray. Optimization of the different boresight directions of the phased arrays within a ground station is shown to significantly increase capacity; for example, this optimization quadruples the capacity for a ground station with eight SFLs. Several networks comprising only two to three ground stations are shown to meet or exceed the capacity of the big dish, Cutting the data rate by half, which saves modem costs and increases the coverage area of each ground station, is shown to increase the average daily capacity of the network for some configurations

Real-Time State Estimation of the EPFL-Campus Medium-Voltage Grid by Using PMUs

We describe the real-time monitoring infrastructure of the smart-grid pilot on the EPFL campus. We experimentally validate the concept of a real-time state-estimation for a 20 kV active distribution network. We designed and put into operation the whole infrastructure composed by the following main elements: (1) dedicated PMUs connected on the medium-voltage side of the network secondary substations by means of specific current/voltage transducers; (2) a dedicated communication network engineered to support stringent time limits and (3) an innovative state estimation process for real-time monitoring that incorporates phasor-data concentration and state estimation processes. Special care was taken to make the whole chain resilient to cyber-attacks, equipment failures and power outages. The achieved latency is within 65ms. The refresh rate of the estimated state is 20ms. The real-time visualization of the state estimator output is made publicly available, as well as the historical data (PMU measurements and estimated states). To the best of our knowledge, the work presented here is the first operational system that provides low-latency real-time state estimation by using PMU measurements of a real active distribution network

The MAORY ICS software architecture

The Multi Conjugate Adaptive Optics RelaY (MAORY) for ESO's Extremely Large Telescope (ELT) is an adaptive optics module offering multi-conjugate (MCAO) and single-conjugate (SCAO) compensation modes. In MCAO, it relies on the use of up to six Laser Guide Stars (LGS) and three Natural Guide Stars (NGS) for atmospheric turbulence sensing and multiple mirrors for correction, providing high Strehl and high sky coverage. In SCAO mode, a single natural source is used as reference, providing better correction but in a smaller field. MAORY will be installed at the Nasmyth focus of the ELT. It will feed the MICADO first-light diffraction limited imager and a future second instrument. MAORY is being built by a Consortium composed by INAF in Italy and IPAG in France and is currently approaching end of phase B. In this paper we describe the preliminary design of the MAORY Instrument Control System Software (ICS SW). We start with an overview of the MAORY module and then describe the general architecture of the MAORY control network and software. We then describe the main software components, with particular emphasis to those managing the NGS and LGS wavefront sensors functions and the AO off-load and secondary loops, and the main interfaces to subsystems and external systems. We then conclude with a description of the software engineering practices adopted for the development of MAORY ICS SW

COVID-19 vaccinations: summary guidance for Cancer patients in 28Languages: breaking barriers to Cancer patient Information

Background: Covid-19 vaccination has started in the majority of the countries at the global level. Cancer patients are at high risk for infection, serious illness, and death from COVID-19 and need vaccination guidance and support. Guidance availability in the English language only is a major limit for recommendations' delivery and their application in the world's population and generates information inequalities across the different populations. Methods: Most of the available COVID-19 vaccination guidance for cancer patients was screened and scrutinized by the European Cancer Patients Coalition (ECPC) and an international oncology panel of 52 physicians from 33 countries. Results: A summary guidance was developed and provided in 28 languages in order to reach more than 70 percent of the global population. Conclusion: Language barrier and e-guidance availability in the native language are the most important barriers when communicating with patients. E-guidance availability in various native languages should be considered a major priority by international medical and health organizations that are communicating with patients at the global level.info:eu-repo/semantics/publishedVersio