Effect of substrate surface roughening and cold spray coating on the fatigue life of AA2024 specimens

The effects of cold spray coating and substrate surface preparation on crack initiation under cyclic loading have been studied on Al2024 alloy specimens. Commercially pure (CP) aluminum feedstock powder has been deposited on Al2024-T351 samples using a cold-spray coating technique known as high velocity particle consolidation. Substrate specimens were prepared by surface grit blasting or shot peening prior to coating. The fatigue behavior of both coated and uncoated specimens was then tested under rotating bend conditions at two stress levels, 180 MPa and 210 MPa. Scanning electron microscopy was used to analyze failure surfaces and identify failure mechanisms. The results indicate that the fatigue strength was significantly improved on average, up to 50% at 180 MPa and up to 38% at 210 MPa, by the deposition of the cold-sprayed CP-Al coatings. Coated specimens first prepared by glass bead grit blasting experienced the largest average increase in fatigue life over bare specimens. The results display a strong dependency of the fatigue strength on the surface preparation and cold spray parameters

Hoisting C Structures Into Clay In Device Drivers

This project addresses the unreliability of operating system code, in particular in device drivers. Device driver software is the interface between the operating system and the device's hardware. Device drivers are written in low level code, making them difficult to understand. Almost all device drivers are written in the programming language C which allows for direct manipulation of memory. Due to the complexity of manual movement of data, most mistakes in operating systems occur in device driver code. The programming language Clay can be used to check device driver code at compile-time. Clay does most of its error checking statically to minimize the overhead of run-time checks in order to stay competitive with C's performance time. The Clay compiler can detect a lot more types of errors than the C compiler like buffer overflows, kernel stack overflows, NULL pointer uses, freed memory uses, and aliasing errors. Clay code that successfully compiles is guaranteed to run without failing on errors that Clay can detect. Even though C is unsafe, currently most device drivers are written in it. Not only are device drivers the part of the operating system most likely to fail, they also are the largest part of the operating system. As rewriting every existing device driver in Clay by hand would be impractical, this thesis is part of a project to automate translation of existing drivers from C to Clay. Although C and Clay both allow low level manipulation of data and fill the same niche for developing low level code, they have different syntax, type systems, and paradigms. This paper explores how C can be translated into Clay. It identifies what part of C device drivers cannot be translated into Clay and what information drivers in Clay will require that C cannot provide. It also explains how these translations will occur by explaining how each C structure is represented in the compiler and how these structures are changed to represent a Clay structure.